I am an occasional user of Haiku, and I just installed and ran the latest release. Overall I am impressed by the variety of applications and the relative stability and it looks like it could be used for daily use and in fact I am trying to setup an 8 year old laptop for an old lady friend of mine, who would happily use it without bias.
The problem is that the network (wireless or wired) seems very slow to the point of barely usable.
On haiku I get typical speeds of 300Kb/s while on linux about 10M/s (I have benchmarked it downloading the haiku image from the same mirror using curl). That is a huge difference.
Since my friend would mostly use a browser with youtube and some social media the load time really is painful. The video playback as well. The youtube main page takes 15 seconds to load on Gnome’s web whereas it is instantaneous on linux.
Any suggestions or tricks? Do I need to install or tune something?
I think it is the intel wireless 7260 card and the wired card is some atheros.
But overall, I am impressed by the availability of software, it does seem possible to use as a daily driver.
Edit: Originally I thought it was just the wireless but I found an ethernet cable after I wrote the first post.
A couple years ago I benchmarket Raw sftp command line transfer speeds on the company network, and Haiku was on par with Linux and MacOSX on same hardware (MacBookPro, Marvel 570 driver) for transferring a 4Gb file to the same destination (less than a couple of % difference, and that test also validates file system read/write speeds ). I’m sorry to read about your poor transfer rates, could be open source driver issue, a regression, the software you’re using, or any number of things.
Thanks for the response. In a past discussion I saw people complaining about slow network and others also claiming that it is on par.
I don’t expect it or need it to be on par with linux. But it is actually 30-40 times slower even on wired network.
I just found out that the wired driver is atheros813x.
My general impression is that the atheros chips are quite open source friendly, so I was expecting really good performance.
Hopefully there is a resolution. It is a heavy laptop (some asus s500ca), so it can stay wired if it makes the network faster.
If you have access to WiFi, regardless of whether you expect to continue using it, try configuring it to see if the WiFi controller gives you faster speeds. If it works but is also slow, the culprit may not be driver based.
To simplify matters, I prefer to debug the wired network first. It is slow when wired as well, so no need to mess with wifi settings I think. But I welcome suggestions on how to debug this.
My suggestion wasn’t using WiFi as a permanent solution at all. What I was suggesting was a comparison of the wireless networking stack to the wired networking stack for speed discrepencies.
The only other way I can think of is trying USB wired networking and looking for speed discrepencies there. It’s all about the speed comparisons to find the bottleneck where the signal speed is getting choked off.
Ah yes, I apologize. Yes. this is reasonable. However for now I can say that the speed, wired or wireless is the same.
Just for the record, over HaikuPorts there’s a “speedtest_cli” package that might come in handy when benchmarking network issues.
It wasn’t working, as it required old Python versions that are not supported anymore. Opened a PR both updating to the newest release, and to make it work on beta4 (and its “default” Python 3.9).
I have a bad internet connection, but it is consistently 10x worse when attempting to update Haiku/HaikuPorts via pkgman/HaikuDepot… does everyone else speed tops around 250/300 KB/s when doing updates from those, or it is just me? (consistent speeds on that for the last 6 months from here in Argentina).
Edit: to avoid confusion, due to the way packaging works for Python “apps”, once that PR gets merged, if you want to use
speedtest-cli (a command line program), you need´ll to install the one named:
speedtest_cli_python39, as in:
pkgman install speedtest_cli_python39 (the one without the “_python39” will be basically empty)
After that, from a Terminal window, calling
> speedtest-cli-python39 should work.
(mind the differences between “-” and “_” on the names of the package vs the name of the program)
Python 3.6 is not available from HaikuDepot anymore, so unless you already have it installed, only
speedtest_cli_python should be installable (as it seems like Python 2.7 is still available, sigh) right now.
At least, that’s what I can gather from the old recipe (requires either “cmd:python2.7” or “cmd:python3.6”).
Will do a check in a bit on 32bit, you converted the PR to draft, more work needed there?
Left a comment on the PR… the recipe was still pulling in Python 2.7… due to a typo (already there on the old recipe) on a variable name.
Will “un-draft” it as soon as I triple-check things
Hello all thanks for the effort. I will be happy to use this lovely command line tool and report my findings. I will check later today if I can use it.
Ok. I ran the speedtest-cli-python39.
It works, but adds to the mystery. It reports speeds of 100Mbits/sec (download) and 30Mbits/sec (upload). Which is what I would expect.
However, actual download speeds using curl are still 300Kb/sec in haiku and 10Mbytes/sec in linux (obviously on the same machine).
When browsing youtube in linux it peaks to around 4-5Mbytes/sec. But in haiku it is some hundreds of Kb/s.
Can it be some network configuration issue?
Aaaand trying to look for network configuration parameters I caused a crash.
Opening the network configuration utility, selecting the wifi and then clicking on the dropdown of all the available wifis (in my case there are hundreds where I live) causes the network preferences application to crash. I will try to report this somewhere, cause it is actually reproducible.
Small update: using wireshark in both linux and haiku (which crashes often), and while downloading a haiku image, I found that there is huge difference in the packet lengths.
In linux the packet length varies around 30000. In haiku it is fixed at 1514 to receive or 66 to send (I hope I interpret this right, I am not a wireshark or network expert).
Is there a reason why in haiku the packet size is 20 times smaller?
Note: this is all in the wired interface.
This smells like wrong MTU is picked/used.
I did change the MTU value (from 9004 to 1500) in haiku. Also I changed it to 9004 in linux. But it does not substantially change the speed of either.
There’s already a ticket for this. The problem is really in the Interface Kit menu handling code, which nobody seems to have dug into yet.
Haiku does not send packets larger than the standard MTU even if you have a larger MTU configured, I think (but will receive them properly, at least after a refactor I did to fix this problem some months ago.) 66-byte packets sending is probably just ACKs and not real data, so not very large.
The most likely difference between throughput here on Linux vs. Haiku is that Haiku’s TCP implementation does not actually do real window scaling. This is not very noticeable on LANs with very low round-trip latency, but becomes increasingly apparent the longer (in time) it is between your machine and the other end of the connection. You will likely see great performance with
curl on LAN just like speedtest indicates.
There is a ticket about this also with some details of what will need to be done to fix the problem, and a hacky patch which sets really huge windows just for testing, showing that the rest of the TCP stack does handle larger windows properly and it massively increases throughput, we just don’t automatically scale to them.