re0 fix that works with polling
Sean McNeil
sean at mcneil.com
Mon Oct 18 16:25:11 PDT 2004
On Mon, 2004-10-18 at 16:02, John-Mark Gurney wrote:
> Sean McNeil wrote this message on Mon, Oct 18, 2004 at 14:31 -0700:
> > Hi John-Marc,
> >
> > On Sun, 2004-10-17 at 18:12, John-Mark Gurney wrote:
> > > John-Mark Gurney wrote this message on Sun, Oct 17, 2004 at 16:28 -0700:
> > > > I'll do some tests shortly to see about these issues...
> > >
> > > Ok, I played around w/ rwatson's netsend program, and I was able to
> > > send 1316 byte payload udp packets at about 28kpps w/o problems.. I
> > > was not able to confirm that no packets were loss, BUT, netstat did
> > > show very close to 28kpps received... At 28kpps, it's far exceeds
> > > your problem of 15Mbps, it is about 38megbytes/sec..
> >
> > I looked at and read netsend/netreceive. Is this what you are using?
>
> yes...
>
> > If so, how do you know that there is no packet loss? netreceive does no
>
> That's what I said, that I was not able to confirm, but if I ran netstat
> on the receiving machine, the number of pps that the receiving machine
> VERY closely matched what I was suppose to receive... I definately did
> not see anything close to 20% packet lose...
>
> > checking to make sure of anything. It is just a sink that throws away
> > the packets. You need to look at the actual data that is being
> > delivered. You will find that 20% of those packets that are suppose to
> > have been sent are just thrown away without any error indication of any
> > sort. netstat -i will show no errors yet the packets are gone if you
> > look for them on the other side. So netsend is telling you it sends
> > them at 38megbytes/sec but out the wire the driver is only sending 80%
> > of the packets it should.
>
> but I was seeing 38megbytes/sec being received at the receiving end...
> yes, I didn't verify that they weren't dups, but that would imply we have
> other issues with the re driver than just this...
>
> Do you have a video that you could send me, that I could do some testing
> with this? (and vls config)? I've been doing my testing on an i386,
> but that shouldn't be different enough to cause problems... (if it is,
> then we need to think about what the re is behaving badly)...
I have placed 11 megs of the stream in
http://mcneil.com/~sean/freebsd/stream.mpg
You can install vls from ports (net/vls) and I run it with
vls -d udp:224.1.1.1:1234 file:stream.mpg
I agree that your assesment appears to be accurate in identifying no
packet loss. Are you going through a switch or is this a cross from
machine-machine?
Please let me know if there is anything I can do to assist. Here is the
output from lspci:
00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169
(rev 10)
Subsystem: Micro-star International Co Ltd: Unknown device 702c
Flags: bus master, 66Mhz, medium devsel, latency 32, IRQ 16
I/O ports at cc00
Memory at cfffb300 (32-bit, non-prefetchable)
Capabilities: [dc] Power Management version 2
I was mistaken about the irq not being shared. On my system, irq 16 is
shared with my vga controller:
01:00.0 VGA compatible controller: nVidia Corporation: Unknown device
0322 (rev
a1) (prog-if 00 [VGA])
Subsystem: PROLINK Microsystems Corp: Unknown device 1152
Flags: bus master, 66Mhz, medium devsel, latency 32, IRQ 16
Memory at ce000000 (32-bit, non-prefetchable)
Memory at c0000000 (32-bit, prefetchable)
Capabilities: [60] Power Management version 2
Capabilities: [44] AGP version 3.0
I run the xorg server.
Cheers,
Sean
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20041018/2430b7b3/attachment.bin
More information about the freebsd-current
mailing list