Retro-regression in Dial-Up Speed Tests in 2025

I had read about a new Internet connection speed test from the Canadian Internet Registration Authority, at https://performance.cira.ca/ and commented on Mastodon that it used a lot of data per test. Typically 50 megabytes per test, on a 15 megabits/second connection, which is annoying on a cell phone plan that has 2 gigabytes per month (I've since moved up to 9GB/month at a cheaper rate!). Supposedly the test scales the amount of data used to fit the bandwidth, so for a lark I wanted to try it on dial-up Internet, which does 4 kilobytes/second at best.

Setting up Dial-up Internet with wvdial and NCF

So I plugged in my trusty Motorola ModemSURFR (circa 1997) and tried to connect to NCF (National Capital Freenet - in Canada), our local volunteer run Internet service provider (they started in dial-up days, now selling higher speed internet using the big telecom wholesale access and NCF servers).

Video of Modem Connecting.mp4, edited for time.

Usually I use the "wvdial" software under Linux (Fedora 41) to connect to the Internet via telephone line, but that wasn't able to log in any more. I even tried manually typing in the user and password using the minicom terminal program, still says I'm not authenticated. By the way, that login used to lead to a text mode menu user interface to NCF (mail, newsgroups, web browsing with Lynx) called FreePort. I submitted a bug report to NCF.

After an afternoon of trying all sorts of things, I was able to manually fire up the Point to Point Protocol daemon (pppd) after connecting with the minicom terminal program, but exiting without typing anything at the login prompt. That's a bit awkward - manually using minicom, exit, start pppd, then run a command to add DNS server settings. But it worked. So maybe the NCF login screens are leftover from earlier times and should be ignored.

Maybe I can get wvdial to skip the login. After reading the documentation, it turns out there is a way, just use "stupid mode" which skips the login attempt and runs pppd right after the modem connects. Problem solved! Updated the bug report at NCF. And for future use, here's my /etc/wvdial.conf file (note the line that slows down the modem to V.34 so it can work over the VoIP fake telephone line I have):

[Dialer Defaults]
# Use wvdialconf with the modem powered up to set initial settings.
Init1 = ATZ
Init2 = ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
# Modulation standards, 9=V.32, 10=V.32bis, 11=V.34, 12=56K
# With voice over IP (Bell Fibe telephone service), max 11.  AGMS20230722
Init3 = AT+MS=11
Modem Type = Analog Modem
# NCF National Capital Freenet modem number in 2023.
Phone = 613-366-0013
ISDN = 0
Username = aa123
Password = PasswordGoesHere
Modem = /dev/ttyS0
Baud = 115200
# May need to manually set DNS with "resolvectl dns ppp0 208.72.120.204" command,
# or put it in the /etc/ppp/up and down scripts, or turn off the resolve service
# so /etc/resolve works again.
# Stupid mode needed for NCF National Capital Freenet.  AGMS20250206
Stupid Mode = 1

Typical Dial-up Speed

Things were somewhat slow. I could see the modem lights flickering almost all the time, except when the connection would drop and restart (spam phone calls were interrupting the connection until I added the *70 pre-dial code to disable call-waiting).

FireFox Browser Caused Slowdown

It seemed that stuff was being sent and received without any action on my part. I turned off various likely services (Windows networking, etc), and finally tracked it down to the Firefox web browser. It was sending performance data back to Mozilla as well as downloading news and weather for display on empty pages. On faster Internet connections, that uses about 8 kilobytes per second, which swamped my 3 kilobyte per second dial-up connection. Fortunately you can turn all of that off, and things were suddenly much less slow. Speed measurements are easily done with the system monitor:

which shows we're getting around 3 kilobytes per seonnd for both send and receive. Though the lines are rather wiggly, which means high jitter. As you can see from a ping test:

the delay from sending a ping to getting a response back varies from a second to 50 seconds, depending on how much other traffic is being received at the same time. At best when nothing is happening, ping time is around 700ms.

The CIRA Speed Tests

Okay, now we have things working well enough to attempt the new CIRA speed tests, and after doing a test with VDSL internet to load the web browser cache with the graphics and maps they display (it would take dozens of minutes to load them on dial-up), you get this for the dial-up test:

It says "No Test Data Captured. Are you connected to the Internet?" I guess their tests starts with data packets that are too big to transmit before their test code's timeout triggers. A smarter test would do a few small packets to see what the speed range is, before ramping up to megabytes of data.

Mini Test

I received a reply from CIRA with a suggestion that I try their mini test. Tried it out,

and was pleasantly surprised to see that it worked, with correct results. Indeed, if you compare the system monitor graph of download activity, you see that it starts out slower (shallower graph slope).

Kudos to CIRA for having more functionality than other tests out there! It doesn't look fancy, but works much better.

The NCF Speed Test

NCF also has a speed test, a rebranded Ookla one. It also wasn't able to handle slow speeds, thinking that it couldn't connect to the test server:

However, it did complete the ping and jitter portions of its test, before trying the download part:

Then it hid the completed numbers under the error message.

Conclusion

It looks like many speed tests are written assuming a current-day range of speeds, and don't handle older computer networks well at all. There should be a word for that. After chatting with an AI (it suggested dumbsizing, feature regression, degradation), I was inspired to coin retro-regression. It happens when novice programmers don't consider the entire situation and leave out past functionality, or when management only wants to target the low hanging fruit and doesn't want to spend time making a complete solution.

Anyway, it's been a blast of nostalgia getting dial-up working again. And a reminder of the pain of slow dial-up speeds when trying to get anything done. I remember reading Tom's Hardware with two pages open in the browser - one to read, the second to load the next page while I was reading. It's been great ever since DSL came along with 6 megabit speeds.

Copyright © 2025 by Alexander G. M. Smith.