4 ms·

Oh, no doubt, but I hold out hope that somehow, some way, somebody will find a way to handle the hug of death. Perhaps it's simply impractical on such modest ha

Oh, no doubt, but I hold out hope that somehow, some way, somebody will find a way to handle the hug of death. Perhaps it's simply impractical on such modest hardware.

serentty 5y ago
I think it would have fared much better if I had waited until I got my ISA Ethernet card in the mail. But serving this over serial at 38400 baud and watching it try to keep up was tempting. I’ll have to see how well it fares with real networking hardware. At that point I might post it again, although I will have to add enough content to it to justify a repost.
- CyberRabbi 5y ago
  Are you able to measure the latency of processing one request when there is no load? Just back of the envelope, if it takes 200,000 instructions to handle a request and we assume 6 cycles per instruction, then that’s about 25 requests per second. HN is roughly 50K requests over 6 hours, so that’s roughly 2 requests per second on average. I would imagine it peaks to about 25. So in theory you should be able to handle the traffic.
  - admax88qqq 5y ago
    The 38400 baud might be the biggest bottleneck. http://bettermotherfuckingwebsite.com/ http://bettermotherfuckingwebsite.com/ is 20k, ignoring http overhead. Maybe strip that to 15k after compression, and cut some content. Still 15000/38400 <= 3 responses per second. Add in serial parity overhead, http overhead. Might be able to sustain 2 rps with enough cleverness. Leaves no room for bursts
    - fisherjeff 5y ago
      Don’t forget that 38400 baud serial is 3840 bytes/s…
      - arcticbull 5y ago
        38400 baud should be 38.4kbits/sec or 4800 bytes/sec no? [edit] never mind, you're right, assuming an 8N1 configuration - 8 bit bytes, 1 start bit, 1 stop bit, and no parity bits.
      - admax88qqq 5y ago
        Yup definitely forgot bits vs bytes lol. So 3kB/s, if your site is 15kB you're looking at 5 seconds per request, or 0.2 rps. Plus overhead. I thought my original math sounded too fast.
      - Moru 5y ago
        A nitpick though from someone that actually used a 300 baud modem without dialing function, baud != bps [0] [0] https://www.linuxjournal.com/files/linuxjournal.com/linuxjournal/articles/010/1097/1097s2.html https://www.linuxjournal.com/files/linuxjournal.com/linuxjou...
- djbusby 5y ago
  The content can be performance metrics before and after the Ethernet card.
tyingq 5y ago
>Perhaps it's simply impractical on such modest hardware I imagine it's not just the hardware limitations, but the available software. This one, for example being MS/DOS, where there were never really any serious server-side http/tcp implementations. On the other hand, there were very busy BBS systems running on DOS where there had been time for years of various optimizations to happen.
outside1234 5y ago
It is probably the modem honestly. The 386 is well capable of saturating a 38.4k modem many times over.

Oh, no doubt, but I hold out hope that somehow, some way, somebody will find a way to handle the hug of death. Perhaps it's simply impractical on such modest hardware.

serentty 5y ago

I think it would have fared much better if I had waited until I got my ISA Ethernet card in the mail. But serving this over serial at 38400 baud and watching it try to keep up was tempting. I’ll have to see how well it fares with real networking hardware. At that point I might post it again, although I will have to add enough content to it to justify a repost.

CyberRabbi 5y ago
Are you able to measure the latency of processing one request when there is no load? Just back of the envelope, if it takes 200,000 instructions to handle a request and we assume 6 cycles per instruction, then that’s about 25 requests per second. HN is roughly 50K requests over 6 hours, so that’s roughly 2 requests per second on average. I would imagine it peaks to about 25. So in theory you should be able to handle the traffic.
- admax88qqq 5y ago
  The 38400 baud might be the biggest bottleneck. http://bettermotherfuckingwebsite.com/ http://bettermotherfuckingwebsite.com/ is 20k, ignoring http overhead. Maybe strip that to 15k after compression, and cut some content. Still 15000/38400 <= 3 responses per second. Add in serial parity overhead, http overhead. Might be able to sustain 2 rps with enough cleverness. Leaves no room for bursts
  - fisherjeff 5y ago
    Don’t forget that 38400 baud serial is 3840 bytes/s…
    - arcticbull 5y ago
      38400 baud should be 38.4kbits/sec or 4800 bytes/sec no? [edit] never mind, you're right, assuming an 8N1 configuration - 8 bit bytes, 1 start bit, 1 stop bit, and no parity bits.
    - admax88qqq 5y ago
      Yup definitely forgot bits vs bytes lol. So 3kB/s, if your site is 15kB you're looking at 5 seconds per request, or 0.2 rps. Plus overhead. I thought my original math sounded too fast.
    - Moru 5y ago
      A nitpick though from someone that actually used a 300 baud modem without dialing function, baud != bps [0] [0] https://www.linuxjournal.com/files/linuxjournal.com/linuxjournal/articles/010/1097/1097s2.html https://www.linuxjournal.com/files/linuxjournal.com/linuxjou...
djbusby 5y ago
The content can be performance metrics before and after the Ethernet card.

tyingq 5y ago

>Perhaps it's simply impractical on such modest hardware I imagine it's not just the hardware limitations, but the available software. This one, for example being MS/DOS, where there were never really any serious server-side http/tcp implementations. On the other hand, there were very busy BBS systems running on DOS where there had been time for years of various optimizations to happen.

outside1234 5y ago

It is probably the modem honestly. The 386 is well capable of saturating a 38.4k modem many times over.