At 08:36 AM 12/15/2001, you wrote: >Hi > > > > > 2.4.16 > > > 100Mbps Switched > > > > > > PCI: Found IRQ 10 for device 00:09.0 > > > eth0: ADMtek Comet rev 17 at 0xe400, 00:04:E2:1E:FE:B3, IRQ 10. > > > using the tulip drivers. > > > > That is roughly 1 error for every 3000 received frames. > > With 'netstat -s' you will possibly see incoming packets > > being dropped: > >yeah i know thats why i asked. > > > Ip: > > 317338 total packets received > > 0 forwarded > > 19 incoming packets discarded > > 220834 incoming packets delivered > >i only get >2 incoming packets discarded > > > Another metric to look at is softnet_stat, these are per CPU (my > > sample box for this is a dual-CPU machine), and the fields counting > > frames are in order: total, dropped, time_squeeze, throttled, > > fastroute_hit, fastroute_success, fastroute_defer, >fastroute_deferred_out, > > cpu_collisions. > > > > # cat /proc/net/softnet_stat > > 0000b7c0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 >00000000 > > 0000bea7 00000000 00000000 00000000 00000000 00000000 00000000 00000000 >00000000 > > > >my current eth0 stats look like > >RX packets:554773 errors:157 dropped:0 overruns:157 frame:157 >TX packets:696401 errors:0 dropped:0 overruns:0 carrier:0 > >i seem to get ># cat /proc/net/softnet_stat >00091fd8 00000000 00000001 00000000 00000000 00000000 00000000 00000000 >00000000 > >what would the time_squeeze be ? >so 0 are dropped by the kernel. >the only thing that would be active is a serial port with a 56k modem >attached to it and hard disks without much io eg only the amount the >network card is putting though which is no more than 2MBytes/sec :( >and the system is about 40% idle on a P233 with 192MB ram > > > > All in all, if your system has many busmasters (TV frame-grabbber, > > busy IDE/SCSI controllers, many network cards), it might do well > > to force lower latency values for them all (at BIOS setup.) The actual error would be useful. You have different kinds of overruns. You could have your receive ring filling up faster than frames are being pulled out (the 40% is meaningless...this occurs instantaneously and it only takes 1 burst to do it)...or it could be an overrun on the card due to an inability to empty the fifo due to bus contention (adjusting the latency wont help much...if data is arriving to the NIC faster than it can empty its fifo, you will get an overrun). This could happen if you get a burst of frames during a disk access... I would put some trace code in interrupt.c of the tulip driver...you'll notice that there are different kinds of errors...fifo errors, frame errors etc...you need to know what you are getting to form a hypothesis. Dennis - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
