Also try increasing the device queue length
by "ifconfig eth0 txqueuelen 1024". In
doing some testing, we found that if you
are really bursty in sending data, the
device queue will silently drop packets
(free them) and I didnt find any stats
which show the dropped packets.
Increasing the queue
"Brian F. G. Bidulock" wrote:
>
> Frank,
>
> Have you considered checking /proc/net/dev_stat (first entry)
> to see whether NET4 is dropping packets due to backlog
> maximums? If there is a non-zero entry there, you might try
> uping /proc/sys/net/core/netdev_max_backlog from the default
> 300
On Tue, 24 Oct 2000, Frank Hansen wrote:
> Looking at the timestamps, it seems that the packets is dropped mainly
> when the disk task calls 'write' in order to flush the buffer to disk.
>
have you tried enabling dma, unmask irq and 32bit io with hdparm?
(i once had problems with a serial ppp
On Tue, 24 Oct 2000, Frank Hansen wrote:
Looking at the timestamps, it seems that the packets is dropped mainly
when the disk task calls 'write' in order to flush the buffer to disk.
have you tried enabling dma, unmask irq and 32bit io with hdparm?
(i once had problems with a serial ppp
"Brian F. G. Bidulock" wrote:
Frank,
Have you considered checking /proc/net/dev_stat (first entry)
to see whether NET4 is dropping packets due to backlog
maximums? If there is a non-zero entry there, you might try
uping /proc/sys/net/core/netdev_max_backlog from the default
300 and see
Also try increasing the device queue length
by "ifconfig eth0 txqueuelen 1024". In
doing some testing, we found that if you
are really bursty in sending data, the
device queue will silently drop packets
(free them) and I didnt find any stats
which show the dropped packets.
Increasing the queue
> The real fix is to add flow control of course.
I'm not so sure---it's very attractive for data acquisition
devices to throw generic UDP packets onto the net to be vacuumed
up by general-purpose machines. (Multicast can be nice
here too; load balancing, redundancy.)
For example, UDP goes
On Tue, Oct 24, 2000 at 10:42:29PM -0100, Frank Hansen wrote:
> /proc/sys/vm/freepages (to 512 1024 1536), which did not seem to yield
> any better performance.
> Disabling interrupts on the IDE drives seemed to roughly halve the
> number of dropped packets (using /sbin/hdparm -c 1 -d 1 -k 1 -u 1
On Tue, 24 Oct 2000, Frank Hansen wrote:
>Using kernel 2.2.17, I experience lots of dropped UDP packets. The setup
>is as follows:
>UDP packets containing measurement data is sent on 100 Mb Ethernet from
>a embedded device to a Pentium III, 256 MB, IDE based PC with a 3Com
>3C905B network
Frank,
Have you considered checking /proc/net/dev_stat (first entry)
to see whether NET4 is dropping packets due to backlog
maximums? If there is a non-zero entry there, you might try
uping /proc/sys/net/core/netdev_max_backlog from the default
300 and see if your loss diminishes.
On Tue, 24
On Tue, 24 Oct 2000, Frank Hansen wrote:
[SNIPPED...]
>
> Any suggestions whatsoever would be greatly appreciated. FWIW NT 4.0
> running on the same hardware performs this task flawless, and I will
> have a diffucult time to convice my boss that we should use Linux as
> long as it is
Using kernel 2.2.17, I experience lots of dropped UDP packets. The setup
is as follows:
UDP packets containing measurement data is sent on 100 Mb Ethernet from
a embedded device to a Pentium III, 256 MB, IDE based PC with a 3Com
3C905B network adapter.
The UDP packets always contains 1300
Using kernel 2.2.17, I experience lots of dropped UDP packets. The setup
is as follows:
UDP packets containing measurement data is sent on 100 Mb Ethernet from
a embedded device to a Pentium III, 256 MB, IDE based PC with a 3Com
3C905B network adapter.
The UDP packets always contains 1300
On Tue, 24 Oct 2000, Frank Hansen wrote:
[SNIPPED...]
Any suggestions whatsoever would be greatly appreciated. FWIW NT 4.0
running on the same hardware performs this task flawless, and I will
have a diffucult time to convice my boss that we should use Linux as
long as it is outperformed
Frank,
Have you considered checking /proc/net/dev_stat (first entry)
to see whether NET4 is dropping packets due to backlog
maximums? If there is a non-zero entry there, you might try
uping /proc/sys/net/core/netdev_max_backlog from the default
300 and see if your loss diminishes.
On Tue, 24
On Tue, 24 Oct 2000, Frank Hansen wrote:
Using kernel 2.2.17, I experience lots of dropped UDP packets. The setup
is as follows:
UDP packets containing measurement data is sent on 100 Mb Ethernet from
a embedded device to a Pentium III, 256 MB, IDE based PC with a 3Com
3C905B network adapter.
On Tue, Oct 24, 2000 at 10:42:29PM -0100, Frank Hansen wrote:
/proc/sys/vm/freepages (to 512 1024 1536), which did not seem to yield
any better performance.
Disabling interrupts on the IDE drives seemed to roughly halve the
number of dropped packets (using /sbin/hdparm -c 1 -d 1 -k 1 -u 1
The real fix is to add flow control of course.
I'm not so sure---it's very attractive for data acquisition
devices to throw generic UDP packets onto the net to be vacuumed
up by general-purpose machines. (Multicast can be nice
here too; load balancing, redundancy.)
For example, UDP goes
18 matches
Mail list logo
