23 ms·

Sparc is not for performance, particularly for benchmarks. BTW, even Linux lose benchmarks to windows often times. We used a Sparc Ultra 10 for a Authenticatio

Sparc is not for performance, particularly for benchmarks. BTW, even Linux lose benchmarks to windows often times. We used a Sparc Ultra 10 for a Authentication server in 2000, it supports concurrent 100K users without any issue, obviously you need to write your own software, but the server is super stable. And yes, we use cheap x86 + Linux for all sorts of thing from 1996 and it was quite faster but you can not trust it the same way as a Sparc.

gorfian_robot 2y ago
we used to 'joke' that you would have to set one of fire to get it to stop responding to a ping. even then, might take a while.
- cable 2y ago
  Been there done that? Circa 2001 I had a customer with a rack of 220R's and Clariion storage arrays. I was paged about an app outage and saw (IIRC) "environmental errors" in the logs about the temperature of the machines. One of the Clariion's, in the same rack, had caught fire which brought the database / app down but the 220R's kept chugging along. Unsurprisingly this was quickly followed a call from the NOC that the fire suppression kicking in and that I should down get there ASAP.
  - hnlmorg 2y ago
    Oh wow. I have plenty of fond memories about the stability of Spark Stations but none as fun as that. Thanks for sharing. I did once have a Bullfrog TSS that survived a literal explosion. They certainly don’t build hardware like they used to.
- pantulis 2y ago
  That was the joke my VMS colleagues said to us the younger unix hotshots.
fidotron 2y ago
My recollection is anyone doing massive concurrency per server (at the time over 10k connections) was moving to using a BSD because of kqueue. We even went through a phase of email on OpenBSD before being bought by a company that insisted on Exchange. Linux didn’t seem to pull decisively ahead of the BSDs until multicore x86 became mainstream. Up until then it always seemed flaky.
- wahern 2y ago
  SunOS had /dev/poll, which the kqueue paper cited as prior art. https://web.archive.org/web/20000823103627/http://docs.sun.com/ab2/coll.40.6/REFMAN7/@Ab2PageView/55123 https://web.archive.org/web/20000823103627/http://docs.sun.c... via citation 4 in https://people.freebsd.org/~jlemon/papers/kqueue.pdf https://people.freebsd.org/~jlemon/papers/kqueue.pdf For a brief moment before epoll came along it looked like Linux would get /dev/poll.[1] In fact, IIRC, epoll started as a /dev/poll implementation. I don't think Sun's /dev/poll ever saw much uptake because, aside from the limitations mentioned the kqueue paper, the pace of software development was much more rapid and dynamic in the FOSS and web worlds, and the center of gravity had already shifted to BSD and Linux. For better and worse, Linux developers seemed more inclined toward adopting extensions from SysV and SunOS/Solaris than from the contemporary BSDs. [1] See, e.g., https://lwn.net/2001/0712/a/devpoll.php3 https://lwn.net/2001/0712/a/devpoll.php3
  - panick21_ 2y ago
    And then Solaris added EventPorts in reaction to kqueue. Arguably they should have just adopted kqueue. Would be much better if both Solaris and Linux had just adopted kqueue. Having that unified accross the 3 major server OSs would have been helpful.
gnufx 2y ago
> Sparc is not for performance, particularly for benchmarks It certainly was from 2011 to 2019: https://en.wikipedia.org/wiki/K_computer https://en.wikipedia.org/wiki/K_computer > obviously you need to write your own software Kerberos ran fine for me on cast-off SPARCstation 10(?) which was well obsolete at the time.

gorfian_robot 2y ago

we used to 'joke' that you would have to set one of fire to get it to stop responding to a ping. even then, might take a while.

cable 2y ago
Been there done that? Circa 2001 I had a customer with a rack of 220R's and Clariion storage arrays. I was paged about an app outage and saw (IIRC) "environmental errors" in the logs about the temperature of the machines. One of the Clariion's, in the same rack, had caught fire which brought the database / app down but the 220R's kept chugging along. Unsurprisingly this was quickly followed a call from the NOC that the fire suppression kicking in and that I should down get there ASAP.
- hnlmorg 2y ago
  Oh wow. I have plenty of fond memories about the stability of Spark Stations but none as fun as that. Thanks for sharing. I did once have a Bullfrog TSS that survived a literal explosion. They certainly don’t build hardware like they used to.
pantulis 2y ago
That was the joke my VMS colleagues said to us the younger unix hotshots.

fidotron 2y ago

My recollection is anyone doing massive concurrency per server (at the time over 10k connections) was moving to using a BSD because of kqueue. We even went through a phase of email on OpenBSD before being bought by a company that insisted on Exchange. Linux didn’t seem to pull decisively ahead of the BSDs until multicore x86 became mainstream. Up until then it always seemed flaky.

wahern 2y ago
SunOS had /dev/poll, which the kqueue paper cited as prior art. https://web.archive.org/web/20000823103627/http://docs.sun.com/ab2/coll.40.6/REFMAN7/@Ab2PageView/55123 https://web.archive.org/web/20000823103627/http://docs.sun.c... via citation 4 in https://people.freebsd.org/~jlemon/papers/kqueue.pdf https://people.freebsd.org/~jlemon/papers/kqueue.pdf For a brief moment before epoll came along it looked like Linux would get /dev/poll.[1] In fact, IIRC, epoll started as a /dev/poll implementation. I don't think Sun's /dev/poll ever saw much uptake because, aside from the limitations mentioned the kqueue paper, the pace of software development was much more rapid and dynamic in the FOSS and web worlds, and the center of gravity had already shifted to BSD and Linux. For better and worse, Linux developers seemed more inclined toward adopting extensions from SysV and SunOS/Solaris than from the contemporary BSDs. [1] See, e.g., https://lwn.net/2001/0712/a/devpoll.php3 https://lwn.net/2001/0712/a/devpoll.php3
- panick21_ 2y ago
  And then Solaris added EventPorts in reaction to kqueue. Arguably they should have just adopted kqueue. Would be much better if both Solaris and Linux had just adopted kqueue. Having that unified accross the 3 major server OSs would have been helpful.

gnufx 2y ago

> Sparc is not for performance, particularly for benchmarks It certainly was from 2011 to 2019: https://en.wikipedia.org/wiki/K_computer https://en.wikipedia.org/wiki/K_computer > obviously you need to write your own software Kerberos ran fine for me on cast-off SPARCstation 10(?) which was well obsolete at the time.