I use a pair of Netgear MCAB1001 MoCA (multimedia over coax cable) adapters for my home theater setup. The connections are: PC-->Cat6-->WNDR3700 router-->Cat6-->MoCA-->coax cable-->MoCA-->Cat6-->bluray player. LAN Speed Test (www.totusoft.com) indicates I have a sustained read/write of 84Mbps over the adapters on large files. Ping latency from my computer to the bluray player is less than 1ms. However, I cannot stream video that is over 16Mbps (with regular surges to 25-30Mbps in high-detail scenes) without intolerable stutter. Even though the MoCA adapters are only supposed to operate on Layer 2 (I think), I believe I have narrowed the problem down to some type of TCP Window problem or packet alteration. Here are the troubleshooting steps I've taken so far:
(If the files are too large, just tell me what I should capture and I'll make new files).
After testing with Jperf, I'm inclined to believe that I have a TCP Window scaling problem. When I stream the video(s) directly from my computer to the bluray player, TCP Window scaling works correctly and allows the video to play stutter-free. However, when I stream the video through the MoCA adapters, something seems to prohibit the TCP Window from growing to the size it needs. Either that or the MoCA adapters are somehow altering packets.
This is my first attempt at performing a detailed study of ethernet protocol. I'm hungry for knowledge but I just don't know what I'm looking at in this case. Are the MoCA adapters interfering with TCP window scaling? Or, are they somehow altering packets?
Kurt--The captures you requested are linked below.
Kurt, Thanks for your initial analysis. I don't yet have the capability to do multipoint captures. In the meantime, I ran some captures under additional circumstances in the hopes that it might reveal something.
INTEL64: Win7 x64 PC, IP=192.168.1.9
Capture 5: Y530 to INTEL64 No MoCA No IPV6 JPerf default settings
Capture 6: Y530 to INTEL64 No MoCA No IPV6 Jperf TCP Window 8K
Capture 7: Y530 to INTEL64 No MoCA No IPV6 Jperf TCP Window 128K
More JPerf captures to come...
I'm hoping you might be able to identify why JPerf behaves one way when the MOCAs are in the topology and a different way when they are not.
The next test I performed was using VLC Media Player on my laptop (Y530) to stream the video from my desktop PC (INTEL64). I'm hoping that by using a player different from the bluray player, we might be able to correlate something.
Capture 8: Y530 to INTEL64 No MoCA No IPV6 VLC Media Player
Capture 9: Y530 Through MoCA to INTEL64 No IPV6 VLC Media Player Stutter Range Marked with Pings (Abbreviated)
Capture 10: Y530 to BD670 No MoCA No IPV6 No Stutter Ping RTT Check
Capture 11 and Capture 12 are dual sniff captures at each end of the topology that you requested.
Take a look specifically at all packets with the SYN flag set, as these will be the ones doing window size and window scaling negotiations. Look for a situation in which the PC or the blueray player tries to enable scaling and the option is rejected. If the rejection comes from the MoCA you have part of the problem. If at the other end in the same time period you see the MoCA trying to negotiate a corresponding scaling and size with its device and being rejected by the PC or blueray, then you have the underlying problem. If not, then it is likely to be a problem with the MoCA implementation. On the other hand, if neither the PC nor the blueray try to set up scaling, then that is the problem.
Even if the ping latency is under 1ms, it could cause the time-bandwidth product to go too large without window scaling. For comparison, when doing the transfer without the MoCAs in the path, confirm that window scaling is being negotiated.
answered 27 May '12, 17:08
Here's my analysis.
The problem is probably related to the MoCA, because it might add delay while trans-coding the data. Maybe it adds delay only in one direction. You can't tell with only one capture point. Unfortunately I have (yet) no idea why there is no problem in capture #4 (file copy via the MoCA). The suspected delay should have an effect there as well.
To verify my delay assumption, you could generate some more captures:
The LG player could compensate by downloading the file with a higher "bit rate" and by using a larger internal buffer, to prevent stutter, if there is not enough data. However, that's apparently not the case, even in capture #1 it requests the data with a much lower bit-rate than it would be possible according to the announced window size. Apparently it downloads just what is needed, which is O.K. for "streaming".
Maybe a firmware update of the LG player could help.
Any other thoughts on this?
BTW: If you think my analysis is plain wrong, please feel free to correct me. I'm willing to extend my knowledge by learning from "weird" real world problems :-)