Opened 7 years ago

Closed 7 years ago

#9078 closed bug (invalid)

FreeBSD network drivers using legacy interrupt wrappers are extremely slow

Reported by: kallisti5 Owned by: axeld
Priority: normal Milestone: R1/alpha4
Component: Network & Internet/Stack Version: R1/Development
Keywords: Cc: premislaus1988@…
Blocked By: Blocking: #8295
Has a Patch: no Platform: All

Description

It has been observed that the marvel yukon driver is extremely slow. tqh reports that it may be a larger overall bug in the FreeBSD wrapper and how it handles legacy interrupt wrappers.

As I think I have seen the same thing on various network cards, lets get a common bug open for it.

I am compiling a list of drivers that use the legacy interrupt wrappers... then lets see if we can flesh out a pattern of bug reports for each affected driver.

Change History (11)

comment:1 by Premislaus, 7 years ago

Blocking: 8295 added
Cc: premislaus1988@… added

comment:2 by kallisti5, 7 years ago

Here are the results of my initial research:

Data was found by examining the calls to bus_setup_intr in each network driver and looking for two factors:

  • NULL in the 4th argument
  • the INTR_FAST flag passed to the 3rd argument

Based on function here:

http://cgit.haiku-os.org/haiku/tree/src/libs/compat/freebsd_network/bus.c#n343

Legacy interrupts:

  • 3com
    • #3288
      Network activity on 3c900 generates many media changes
  • broadcom440x
    • No results
  • dec21xxx
    • No results
  • ipro100
    • #8750
      Intel 82552 ethernet chip is not working
  • marvell_yukon
    • No results
  • rtl8139
    • #6059
      FTPD receiving network data takes way too much CPU (rtl8139)
  • syskonnect
    • No results
  • via_rhine
    • No results
  • vt612x
    • No results
  • wlan/atheroswifi
  • wlan/aironetwifi
  • wlan/broadcom43xx
  • wlan/iprowifi3945
  • wlan/iprowifi2100
  • wlan/ralink2860
  • wlan/wavelanwifi
  • wlan/marvell88w8363
  • wlan/ralinkwifi
  • wlan/iprowifi4965
  • wlan/iprowifi2200

Not legacy interrupts:

Could be either:

Last edited 7 years ago by kallisti5 (previous) (diff)

comment:3 by kallisti5, 7 years ago

I plugged a rtl8139 pci card into my hrevr1alpha4-44608 system (which should be using legacy interrupts) and didn't see the reported slowdowns. I downloaded the Haiku disk image as well as linux kernel.

Local network ping times remained in the < 1ms range, and remote (google.com) ping times remained in the 30ms range.

comment:4 by tqh, 7 years ago

Ah then it gets harder, perhaps check how interrupts are acknowledged/disabled by different drivers. It would be really good if people with slow network cards report what card they have.

It could be it is just a problem with i4965 and marvell yukon. Given that yukon does not use wlan code at all, it might be easier to try and see what's the problem there first. I don't have a marvell yukon so I can't do much. I do have a i4965 and it tops out at 100KB/s under Haiku, while on Linux it is at least >20 times faster. Pinging the router goes from <2ms to 1s if you start a download, but returns to <2ms if you stop the download. i4965 uses a lot of locking and do heavy handling in the int handler so I suspect lock contention. I think there is something to be learned by how FreeBSD does (MSI?) int handling, havn't got the time to look into it yet.

Btw have you checked that it is using the 8139 driver? IIRC some generations are more like 8169. You might also want to compare cpu usage.

comment:5 by kallisti5, 7 years ago

I plan on doing some more testing here... but I've not been able to reproduce any issues with these legacy interrupt cards. (the 8139 I tested was using the 8139 driver as per listimage)

I'd say this issue may be limited to marvell_yukon given the lack of open issues for other cards in comment:2

Going to try and test a few more cards that use 'legacy interrupts' then close this.

comment:6 by kallisti5, 7 years ago

I haven't seen this on any PCI network cards (i've tried 4-5 now)... this may be only something that is seen on laptop internal NIC's?

I have an old P4 laptop stashed away, let me pull it out, dust it off and try the latest R1A4 nightly on it.

Last edited 7 years ago by kallisti5 (previous) (diff)

comment:7 by tqh, 7 years ago

Then maybe it isn't a problem. From lock usage info on i4965 I suspect it is, but might just be on my card / network / ...

See https://plus.google.com/u/0/116713839708821747722/posts/QpUzBRczywm for some info on my measurements.

in reply to:  7 comment:8 by mmlr, 7 years ago

Replying to tqh:

Then maybe it isn't a problem. From lock usage info on i4965 I suspect it is, but might just be on my card / network / ...

I think the semaphore in question isn't used as a lock but as a signal. Basically the thread in question is always waiting on the semaphore unless there is an action to be taken (i.e. a task is added to the queue). So high wait times are to be expected here.

comment:9 by kallisti5, 7 years ago

I should note, booting R1A4 anyboot from a CD on the Dell GX620 next to me resulted in the following (at least twice now)

  • Deskbar frozen
  • Running ifconfig from the terminal results in a frozen ifconfig process.

I ended up needing to reboot to get it moving again. Network cards are broadcom570x and 3com.

No network lag though when it's working.. when the above occurs i can't get out of the local machine.

comment:10 by kallisti5, 7 years ago

Maybe the NetworkStatus app is locked somehow that is locking the Deskbar?

comment:11 by kallisti5, 7 years ago

Resolution: invalid
Status: newclosed

this seems like something too hard to fix pre-r1a4. closing as a solution was found for #8454

Note: See TracTickets for help on using tickets.