Noah Beck wrote: > eth0 Link encap:Ethernet HWaddr 00:0D:FE:0C:61:DC > inet addr:192.168.2.10 Bcast:192.168.2.255 Mask:255.255.255.0 > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:10313106 errors:86576 dropped:0 overruns:86576 frame:0 > TX packets:4407772 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:539512246 (514.5 MiB) TX bytes:0 (0.0 B) > Interrupt:27 Base address:0xd300 DMA chan:1 > > Any idea what causes that?
Using exclusively MhthTV protocol, I'm seeing the same overrun symptom, in conjunction with the UI slowing down (typically to the point where I have to do a warm power cycle). It occasionally leads to an error box complaining that there was an error in communications with the MhthTV back-end. It occurs typically after watching a video, and very frequently after deleting a recording. I've been discussing this issue with Michael Drons, who has suggested a number of things to try, such as forcing the Ethernet duplex and speed settings. The last suggestion was to try a direct connection between the MVP and the back-end to rule out cabling and switches, but I've been putting off trying that due to the inconvenience of setting it up. (A direct connection means you need to run a DHCP server on your back-end machine, and have a cross over cable handy.) I'm also not convinced this is an Ethernet hardware problem. Particularly now with reports from others showing up. Although that might just be coincidental, it further increases my suspicion that there may be an issue with a driver or some other low-level software in the mvpmc distribution that isn't behaving well - perhaps only on H3 hardware. Hugo van der Kooij wrote: > An overrun is simply a packet which is larger then the maximum allowed > ethernet packetsize. Actually an overrun occurs when the receive buffer fills up. This can happen when the buffer is too small to ride out momentary slowness in the receiving machine. But increasing the size of the receive buffer by too much can also lead to this same problem, if the receiving machine isn't capable of keeping up with the sustained data flow. This is because the the transmit window (how many packets the transmitting side will send before waiting for an ACK) is calculated based on the receive buffer size, so if that buffer is big, the window is also big, and normal Ethernet flow control won't limit the data rate. I'll forward one of the messages I exchanged with Michael Drons that has more on this and links to reference material. -Tom ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Mvpmc-users mailing list Mvpmc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mvpmc-users mvpmc wiki: http://mvpmc.wikispaces.com/
