> > > >
> > > >
>
> James, Casey,
>
> 1. Dont be overly self-congratulatory : the correct way to look
> at these errors is to see that it has lost 1 packet in 1 day of running (I
> rebooted about a day ago). Over a period of a month, I've seen the errors
> mount upto 200 - 300 packets lost. To my mind, the percentage lost isnt
> whats important - its the magnitude of the loss that matters. BTW, I use
> WinXX too (not that I'm ecstatic about it, but still...).
no i would take a percentage of error because network media
gets errors on a cable anyway this is why there are checksums
to detect these errors in say tcp/ip
normally you would get 1 in 1 billion bits or so but i am not sure
on the average figures for this so dont quote me on it.
windows does not show much info about detailed stats
so the errors can still be there but just not reabable.
> 2. Can a buffer overrun be compensated for by tuning kernel /
> card settings / driver parameters?
not really though in your case it might be able to because its on the TX
if they are on the RX you cannot controll what is sent to the computer
form the computer well not in current kernels this is going to be included
in 2.5.x kernels because it is still currently a problem.
> 3. I dont follow what you mean by "..should not get 1 on the TX
> stats.". Where else would an overrun be reported?
the strange thing is you should not be able to get a buffer overrun on
a transmit because it kind of works something like this on a simple NIC
from a driver
1 setup DMA / packet to send
2 tell the card to transmit and use DMA or
else copy the packet to the card via PIO
3 wait for notice from the card about sending info
eg wether there was an error (media / timeout etc..)
then the packet has been sent or not.
thus is is almost impossible to get a buffer overrun
unless these are not what i am thinking about what
NIC are you using ?
and did you get anything in the dmesg output ?
James
-
: 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
