Re: xircom_cb problems

Re: xircom_cb problems

[Tom Sightler]

[-- Attachment #1: Type: text/plain, Size: 1150 bytes --]

Whoops!! Sorry, forgot the attachment.

Thanks,
Tom


> Both of these are slow, actually. I'm getting 7.5-8MB/s when receiving
> from a 100Mbit box (tulip or starfire, doesn't seem to matter). 
> Transmitting is still slow for me, but that is most likely a different 
> problem -- and I'm looking into it.

Yeah, I knew they were both slow, but at least one is acceptable, the <200KB/s
is below usable when doing any network based work.

> Moreover, I'm getting 9+MB/s in both directions when using the other 
> driver (xircom_tulip_cb), patched to do half-duplex only. So the card
> can definitely transfer at network speeds.

I'm not doing nearly as well with the other driver, but I don't have it patched
for half-duplex only.  I tried setting the remote end to force half-duplex but
this didn't seem to work quite right.


> Looking forward to seeing them...

OK, I tried your patch, it did fix the problem where pump wouldn't pull an IP
address, but I'm still having the problem where my ping times go nuts.  I've
attached an example, it's 100% repeatable on my network at work.  It was so bad
I couldn't get any benchmark numbers.

Later,
Tom


[-- Attachment #2: /root/xircom-slow-pings.txt --]
[-- Type: text/plain, Size: 1975 bytes --]


[root@iso-2146-l1 ttsig]# ping 10.10.4.254
PING 10.10.4.254 (10.10.4.254) from 10.10.4.33 : 56(84) bytes of data.
64 bytes from 10.10.4.254: icmp_seq=3 ttl=255 time=590 usec
64 bytes from 10.10.4.254: icmp_seq=0 ttl=255 time=2.996 sec
64 bytes from 10.10.4.254: icmp_seq=1 ttl=255 time=2.000 sec
64 bytes from 10.10.4.254: icmp_seq=2 ttl=255 time=1.000 sec
64 bytes from 10.10.4.254: icmp_seq=7 ttl=255 time=575 usec
64 bytes from 10.10.4.254: icmp_seq=4 ttl=255 time=3.000 sec
64 bytes from 10.10.4.254: icmp_seq=5 ttl=255 time=2.000 sec
64 bytes from 10.10.4.254: icmp_seq=6 ttl=255 time=1.000 sec

--- 10.10.4.254 ping statistics ---
10 packets transmitted, 8 packets received, 20% packet loss
round-trip min/avg/max/mdev = 0.575/1500.228/3000.710/1117.327 ms
[root@iso-2146-l1 ttsig]# rmmod xircom_cb
rmmod: module xircom_cb is not loaded
[root@iso-2146-l1 ttsig]# lsmod
Module                  Size  Used by
appletalk              18352   0  (autoclean)
serial                 44864   0 
vmnet                  16448   1 
vmmon                  18352   0 
r128                  145392   1 
agpgart                13568   3  (autoclean)
usb-uhci               20864   0  (unused)
usbcore                48176   1  [usb-uhci]
[root@iso-2146-l1 ttsig]# ping 10.10.4.254
PING 10.10.4.254 (10.10.4.254) from 10.10.4.33 : 56(84) bytes of data.
64 bytes from 10.10.4.254: icmp_seq=0 ttl=255 time=955 usec
64 bytes from 10.10.4.254: icmp_seq=1 ttl=255 time=492 usec
64 bytes from 10.10.4.254: icmp_seq=2 ttl=255 time=453 usec
64 bytes from 10.10.4.254: icmp_seq=3 ttl=255 time=465 usec
64 bytes from 10.10.4.254: icmp_seq=4 ttl=255 time=451 usec
64 bytes from 10.10.4.254: icmp_seq=5 ttl=255 time=455 usec
64 bytes from 10.10.4.254: icmp_seq=6 ttl=255 time=450 usec
64 bytes from 10.10.4.254: icmp_seq=7 ttl=255 time=453 usec

--- 10.10.4.254 ping statistics ---
8 packets transmitted, 8 packets received, 0% packet loss
round-trip min/avg/max/mdev = 0.450/0.521/0.955/0.166 ms

Re: xircom_cb problems

[Arjan van de Ven]

Tom Sightler wrote:
> 
> Whoops!! Sorry, forgot the attachment.
> 
>   ------------------------------------------------------------------------
> 
> [root@iso-2146-l1 ttsig]# ping 10.10.4.254
> PING 10.10.4.254 (10.10.4.254) from 10.10.4.33 : 56(84) bytes of data.
> 64 bytes from 10.10.4.254: icmp_seq=3 ttl=255 time=590 usec
> 64 bytes from 10.10.4.254: icmp_seq=0 ttl=255 time=2.996 sec
> 64 bytes from 10.10.4.254: icmp_seq=1 ttl=255 time=2.000 sec
> 64 bytes from 10.10.4.254: icmp_seq=2 ttl=255 time=1.000 sec
> 64 bytes from 10.10.4.254: icmp_seq=7 ttl=255 time=575 usec
> 64 bytes from 10.10.4.254: icmp_seq=4 ttl=255 time=3.000 sec
> 64 bytes from 10.10.4.254: icmp_seq=5 ttl=255 time=2.000 sec
> 64 bytes from 10.10.4.254: icmp_seq=6 ttl=255 time=1.000 sec
> 

This matches exactly with what I think is the problem; now to find the
code
that causes it...

Re: Linux 2.4.5-ac9

[Ion Badulescu]

On Wed, 6 Jun 2001 13:20:41 -0400, Tom Sightler <ttsig@tuxyturvy.com> wrote:
>> 2.4.5-ac9
> 
>> o Fix xircom_cb problems with some cisco kit (Ion Badulescu)
> 
> I'm not sure what this is supposed to fix, but it makes my Xircom
> RBEM56G-100 almost useless on my network at the office.  Actually, I can't
> quite blame just this patch, it only makes the problem worse, the driver
> from 2.4.5-ac3 worked, but with 1 second ping times, the new driver barely
> works at all, it seems to think the link is not there, at least not enough
> to pull an IP address.

The patch does only one thing: it instructs the card not to negotiate
full-duplex modes, because (for undocumented and yet unexplained reasons)
full-duplex modes don't work well on this card.

If you had problems before, then their cause is most likely elsewhere.
1-second ping time is definitely wrong.

> The last driver that worked moderately well for me was the one from
> 2.4.4-ac11, it still had a few issues, mostly when resuming, but everything
> worked at home on my 10Mb hub, and at the office on my 10/100Mb FD Cisco
> 6509.  I must admist that I haven't tested every version in between.

The thing is, I don't really see any significant differences between the
2.4.4-ac11 driver and the 2.4.5-ac9 driver. I see lots of clean-ups, some
power management stuff, and the half-duplex stuff. None of them should
affect the core functionality directly..

Please do me a favor: comment out the call to set_half_duplex() (in
xircom_up), recompile and see if it makes a difference.

> One other note, the version in 2.4.4-ac11 is listed as 1.33 while the
> version in 2.4.5-ac9 is 1.11, why did we go backwards?  Were there
> significant problems with the newer version?  The 1.33 sure seems to work
> better for me.

The CVS version is almost irrelevant, I guess Arjan simply rebuild his
repository.

Ion

-- 
  It is better to keep your mouth shut and be thought a fool,
            than to open it and remove all doubt.

xircom_cb problems

[Tom Sightler]

> The patch does only one thing: it instructs the card not to negotiate
> full-duplex modes, because (for undocumented and yet unexplained
> reasons)
> full-duplex modes don't work well on this card.
> 
> If you had problems before, then their cause is most likely elsewhere.
> 1-second ping time is definitely wrong.

Well, I compiled the driver from 2.4.4-ac11, 2.4.5-ac3, and 2.4.5-ac9 all with
the exact same source from 2.4.5-ac9, and my problems are 100% repeatable on my
hardware.

At home where I have a 10Mb half-duplex hub connection all of the drivers work
properly.

At work where I have a 10/100Mb full-duplex switch connection the drivers work
exactly as I described before:

2.4.4-ac11 -- mostly works fine -- minor problems awaking from sleep

2.4.5-ac3 -- seems to work but pings are >1 second (yes really a full second)

2.4.5-ac9 -- keeps logging "Link is absent" then "Linux is 100 mbit" over and
over when trying to pull an IP address via dhcp using pump or dhcpcd. 
Interestingly manually setting an IP address seems to work fine with this driver.

> The thing is, I don't really see any significant differences between
> the
> 2.4.4-ac11 driver and the 2.4.5-ac9 driver. I see lots of clean-ups,
> some
> power management stuff, and the half-duplex stuff. None of them should
> affect the core functionality directly..

I looked at this before posting, and generally agree, but the results are 100%
reproducable on my machine as listed above, so they must be having some affect.
 My current working system is 2.4.5-ac9 with the driver source from 2.4.4-ac11
recomiled for it and it's working great (minor resume problems aside).

> Please do me a favor: comment out the call to set_half_duplex() (in
> xircom_up), recompile and see if it makes a difference.

I'll do this tomorrow morning when I get in and report back.  Thanks for the
help, I'd really like to see this card get stable as we have it in a lot of our
laptops here at work.

> > One other note, the version in 2.4.4-ac11 is listed as 1.33 while
> the
> > version in 2.4.5-ac9 is 1.11, why did we go backwards?  Were there
> > significant problems with the newer version?  The 1.33 sure seems to
> work
> > better for me.
> 
> The CVS version is almost irrelevant, I guess Arjan simply rebuild his
> repository.

And you would be correct as Arjan confirmed in a follow up messages, sorry about
that, it just looked strange.

Thanks for the help,
Tom

Re: xircom_cb problems

[Ion Badulescu]

On Wed, 6 Jun 2001, Tom Sightler wrote:

> At home where I have a 10Mb half-duplex hub connection all of the drivers work
> properly.

All right, that's expected.

> At work where I have a 10/100Mb full-duplex switch connection the drivers work
> exactly as I described before:
> 
> 2.4.4-ac11 -- mostly works fine -- minor problems awaking from sleep

Can you run some performance testing with this driver, though? The speed
of ftp transfers in both directions would be a good measure. The reason
I'm asking is because we saw really poor performance on 100Mb full-duplex,
something like 200-300KB/s when receiving.

> 2.4.5-ac9 -- keeps logging "Link is absent" then "Linux is 100 mbit" over and
> over when trying to pull an IP address via dhcp using pump or dhcpcd. 

pump likes to bring the interface up and down and up and down, so those 
messages are not necessarily unusual.

Hmm. I have an idea though. In set_half_duplex, we shouldn't touch the MII 
if the new autoneg value is the same as the old one. It should certainly 
help with things like pump. Arjan, what do you think?

> Interestingly manually setting an IP address seems to work fine with
> this driver.

That's very good to know. So most likely the repeated up/down that pump's 
doing is upsetting the card.

> I'll do this tomorrow morning when I get in and report back.  Thanks
> for the help, I'd really like to see this card get stable as we have
> it in a lot of our laptops here at work.

And we'd like to thank you for your patience and for your help diagnosing 
the problem. Let's hope we can solve it quickly..

I'm attaching a small patch that does what I proposed above -- can you 
give it a try as well?

Thanks,
Ion

-- 
  It is better to keep your mouth shut and be thought a fool,
            than to open it and remove all doubt.
------------------------
--- linux-2.4-ac/drivers/net/pcmcia/xircom_cb.c.old	Thu Jun  7 01:27:07 2001
+++ linux-2.4-ac/drivers/net/pcmcia/xircom_cb.c	Thu Jun  7 01:28:13 2001
@@ -1092,13 +1092,15 @@
 
 	/* tell the MII not to advertise 10/100FDX */
 	tmp = mdio_read(card, 0, 4);
-	printk("xircom_cb: capabilities changed from %#x to %#x\n",
-	       tmp, tmp & ~0x140);
-	tmp &= ~0x140;
-	mdio_write(card, 0, 4, tmp);
-	/* restart autonegotiation */
-	tmp = mdio_read(card, 0, 0);
-	mdio_write(card, 0, 0, tmp | 0x1200);
+	if (tmp != tmp & ~0x140) {
+		printk("xircom_cb: capabilities changed from %#x to %#x\n",
+		       tmp, tmp & ~0x140);
+		tmp &= ~0x140;
+		mdio_write(card, 0, 4, tmp);
+		/* restart autonegotiation */
+		tmp = mdio_read(card, 0, 0);
+		mdio_write(card, 0, 0, tmp | 0x1200);
+	}
 
 	if (rx)
 		activate_receiver(card);

Re: xircom_cb problems

[Tom Sightler]

Quoting Ion Badulescu <ionut@cs.columbia.edu>:

> > 2.4.4-ac11 -- mostly works fine -- minor problems awaking from sleep
> 
> Can you run some performance testing with this driver, though? The
> speed
> of ftp transfers in both directions would be a good measure. The
> reason
> I'm asking is because we saw really poor performance on 100Mb
> full-duplex,
> something like 200-300KB/s when receiving.

OK, I did some simple FTP benchmarking, transferring a 100MB to and from my 
laptop connected to a Cisco Catalyst 6509.  The other systems were a PIII 
700Mhz UP with eepro100 NIC running 2.4.2-ac11, and a PIII 1Ghz SMP (2 proc) 
with Alteon Gigabit NIC running 2.2.19.

Transferring files between the eepro100 machine running 2.4.2-ac11 and my 
laptop produced a result of 2.24MB/s for sending and 2.13MB/s recieving the 
file.

Transfering files between the Alteon Gigabit machine running 2.2.19 and my 
laptop resulted in the dismal numbers of 249KB/s sending and 185KB/s recieving, 
close to the numbers you quoted above, but actually slightly worse.

I'm not sure what would explain the 2.2.19 1GB conencted box being 10x slower 
than the 2.4.2-ac11 100MB machine.

Transferring the same file between the two other boxes gives 9.81MB/s which is 
near the theoretical maximum for 100Mb.

> > 2.4.5-ac9 -- keeps logging "Link is absent" then "Linux is 100 mbit"
> over and
> > over when trying to pull an IP address via dhcp using pump or dhcpcd.
> 
> 
> pump likes to bring the interface up and down and up and down, so those
> 
> messages are not necessarily unusual.

Yea, I've actually complained of this before, the interface up/down things that 
pump does makes it very tough to use on a large network with full spanning tree 
as pump brings the interface down and up again right about the time spanning 
tree puts the port into forwarding mode.  I can get around this by setting 
Cisco's portfast feature, but doing that on all ports somewhat defeats the 
purpose of spanning tree and I move my laptop a lot.
 
> Hmm. I have an idea though. In set_half_duplex, we shouldn't touch the
> MII 
> if the new autoneg value is the same as the old one. It should certainly
> 
> help with things like pump. Arjan, what do you think?
> 
> > Interestingly manually setting an IP address seems to work fine with
> > this driver.
> 
> That's very good to know. So most likely the repeated up/down that
> pump's 
> doing is upsetting the card.

Commenting out the set_half_duplex made the driver in 2.4.5-ac9 work with DHCP 
again so your probably right.
 
I'll apply your patch with the change to MII handling and rerun some simple 
file transfers and report the results soon.

Thanks,
Tom

Re: xircom_cb problems

[Ion Badulescu]

On Thu, 7 Jun 2001, Tom Sightler wrote:

> Transferring files between the eepro100 machine running 2.4.2-ac11 and my 
> laptop produced a result of 2.24MB/s for sending and 2.13MB/s recieving the 
> file.
> 
> Transfering files between the Alteon Gigabit machine running 2.2.19 and my 
> laptop resulted in the dismal numbers of 249KB/s sending and 185KB/s recieving, 
> close to the numbers you quoted above, but actually slightly worse.
> 
> I'm not sure what would explain the 2.2.19 1GB conencted box being 10x slower 
> than the 2.4.2-ac11 100MB machine.

Both of these are slow, actually. I'm getting 7.5-8MB/s when receiving 
from a 100Mbit box (tulip or starfire, doesn't seem to matter). 
Transmitting is still slow for me, but that is most likely a different 
problem -- and I'm looking into it.

Moreover, I'm getting 9+MB/s in both directions when using the other 
driver (xircom_tulip_cb), patched to do half-duplex only. So the card can 
definitely transfer at network speeds.

> I'll apply your patch with the change to MII handling and rerun some simple 
> file transfers and report the results soon.

Looking forward to seeing them...

Thanks,
Ion

-- 
  It is better to keep your mouth shut and be thought a fool,
            than to open it and remove all doubt.

Re: xircom_cb problems

[Tom Sightler]

> Both of these are slow, actually. I'm getting 7.5-8MB/s when receiving
> from a 100Mbit box (tulip or starfire, doesn't seem to matter). 
> Transmitting is still slow for me, but that is most likely a different 
> problem -- and I'm looking into it.

Yeah, I knew they were both slow, but at least one is acceptable, the <200KB/s
is below usable when doing any network based work.

> Moreover, I'm getting 9+MB/s in both directions when using the other 
> driver (xircom_tulip_cb), patched to do half-duplex only. So the card
> can definitely transfer at network speeds.

I'm not doing nearly as well with the other driver, but I don't have it patched
for half-duplex only.  I tried setting the remote end to force half-duplex but
this didn't seem to work quite right.


> Looking forward to seeing them...

OK, I tried your patch, it did fix the problem where pump wouldn't pull an IP
address, but I'm still having the problem where my ping times go nuts.  I've
attached an example, it's 100% repeatable on my network at work.  It was so bad
I couldn't get any benchmark numbers.

Later,
Tom

Re: xircom_cb problems

[Ion Badulescu]

On Fri, 8 Jun 2001, Tom Sightler wrote:

> OK, I tried your patch, it did fix the problem where pump wouldn't
> pull an IP address, but I'm still having the problem where my ping
> times go nuts.  I've attached an example, it's 100% repeatable on my
> network at work.  It was so bad I couldn't get any benchmark numbers.

Just one more question: do you see the same bad ping times if you
completely comment out the call to set_half_duplex?

Thanks,
Ion

-- 
  It is better to keep your mouth shut and be thought a fool,
            than to open it and remove all doubt.

Re: xircom_cb problems

[Tom Sightler]

Quoting Ion Badulescu <ionut@cs.columbia.edu>:

> On Fri, 8 Jun 2001, Tom Sightler wrote:
> 
> > OK, I tried your patch, it did fix the problem where pump wouldn't
> > pull an IP address, but I'm still having the problem where my ping
> > times go nuts.  I've attached an example, it's 100% repeatable on my
> > network at work.  It was so bad I couldn't get any benchmark
> numbers.
> 
> Just one more question: do you see the same bad ping times if you
> completely comment out the call to set_half_duplex?

No, the problem goes away if I do this, although then I hae the performance
problems as before.  I also noticed that even when the call to set_half_duplex
is left in, the switch reports that the link is still in full duplex, 100Mb
mode.  I tried forcing half duplex on the switch but this didn't help.  It
actually looks like half duplex is not really being set correctly.

I plugged in a desktop with an eepro100 based card and forced the duplex to half
with the command line options and the switch properly reported a half-duplex
link had been negotiated, with the xircom card the switch reports full-duplex
with or without the set_half_duplex line, which certainly implies it's not
really working right.

Hope the helps.  I won't be back at the office until Monday so that's the
earliest I'll be able to test again, but I'll be glad to test any combination
that I can.

Later,
Tom