4 ms·

Agreed. And I may be showing my age, but I learned C and C++ on singles MIPS boxes (R3000 processors) shared between 20 users, all on X terminals. The thought o

Agreed. And I may be showing my age, but I learned C and C++ on singles MIPS boxes (R3000 processors) shared between 20 users, all on X terminals. The thought of sharing 1 32-bit processor running at 25Mhz between 20 people running any kind of graphical environment it pretty wild by today's standards.

ddingus 7y ago
I am just gonna ramble for a minute. Plz either indulge or ignore. I miss this stuff! Thanks. I would have loved to profile that little system. It's crazy how lean those older systems really were. A 30Mhz R4K could play MP3 files streamed via NFS. (90 percent CPU utilization, not headless, with local desktop logged in and active) I had one, at that clock useless by the time I got it, doing just that, because why not? After reading your comment, I realize I had a machine just playing a compressed audio file with the resources needed to serve 20 of you a useful computing environment! What kind of network were you on? Was it even ethernet? 10T? My first multi-user experience was horrible! It was on a 386/25, running Xenix and it had capacity for 16 users via either 19200 or 9600 baud SERIAL and VT100 terminals... I had 12 users at peak on that one, and most of them ran multi-user WordPerfect and some MRP thing, Symix, I think. I got the job because I read all the manuals. First sysadmin post and it was a pig. Learned a ton though! Enough to realize I could have a lot of fun on the better UNIXes, and scored a position working with SGI computers. (in that timeframe those computers with all the spiffy software so well engineered were like computing from the future, so much fun) Another time, while doing sysadmin on an SGI Irix multi-cpu Origin system serving some 30 users doing high end cad, I did some data logging. That system had 16GB Ram, 4 R12K CPU's with super fat caches, dual homed 1000T ethernet, BTW. I forget the clock. Probably 400Mhz I logged user activity every few seconds for roughly a week. This was an effort to see whether overall system speed was impacting productivity. I had a few users grumble during a peak time, so... Learned a few things: The system itself could perform near max capability when there were 4 concurrent user CAD demands. OS overhead was a few percent tops, in almost all circumstances. This was not in of itself any kind of issue. Irix ran pretty damn lean. Once in a blue moon, the system would page, but the Irix file caches are gold. This never really was an issue either. Maybe for a few minutes at a time during a serious push tops. A few times per week, usually on a Friday, they would max it out, and more than 4 concurrent, high demand sessions would be present. Deffo slowdown. Among the users, the average full compute demand was roughly 2 minutes. Some instances of this were longer for power users working on more substantial models. 5 to 10 minutes. These were sporadic, during the day. The reason was simple, and it was a model recompute. Happens as users roll up all their changes. Interestingly, light duty users, doing detail drawings, or minor model updates, sustaining engineering type stuff, they used the system heavy, perhaps 60 percent of their workday, but rarely hit peak single core compute for more than a few seconds at a time. Was hard to even see these. They did not really do big recomputes, but they did do the occasional big drawing render, and those were as bad as the power users. But not even daily. Most users hit the system both harder and less frequently. 20 to 30 percent of their day, but did post up regular ~2minute single core max compute demands. These people were working on sub systems, and would often copy one, modify, update, check it in, done, next. The power users hit the ~5 to 10 minute peak compute and used the system half the day. They were working at the entire product level. Big demands on RAM, CPU, Network. Multiple times daily. What I did was put local compute resources in front of the power users and restructure the network to give them a quieter, higher throughput subnet. There were a few of these users. They did became network bound, as the data transfer was significant compared to everyone else running on the main server, with high throughput disks. (15K RPM Cheetah drives) This impacted their get going times, but they only did that occasionally. Once things got cached locally, non issue overall. They adjusted how they work and marginalized it. The biggest saving was honestly to just keep it logged in, screen locked, etc... The rest of the users reported a significant speed up after these things were done. Now, here's the thing! A second data logging actually did show the power users improve. And they responded by burying those boxes, opening up a second session on the main one to continue. LOL, fine. It was good enough before, so I said nothing. They were power users and working at the product level and gains there paid off nicely in terms of total project capacity per year. No worries. There to help, blah, blah. But I did chuckle about them very rapidly figuring out how things worked. (They used the excellent virtual desktop feature in the 4dwm window manager common to SGI computers. One click and they were viewing their local session, one more click and they were viewing their remote one, next.) But everyone else demonstrated no real change! The data just was not there to support a big gain, and it totally was not there after the power users did their thing by running two sessions anyway. So, what was it? Turned out to be network. When I put the local compute where it needed to be, we moved some switches and had inadvertently improved load balancing at the physical layer. Some users, prior to this, were basically blocking others. Latency went down for everyone, and average throughput went up, and that proved to be the single most gratifying improvement for them, and it was just faster interactive response. No effective change in actual compute / time unit available, nor demanded from them. The parallels today are obvious. Get that page response time down. Effective throughput, what users can get done may bump up a little, but the vast majority won't do it. But, their feel, perception will ramp right up to the positive. This is true even when it comes at the expense of other things maybe being slower, taking longer. Just get them feedback NOW, and they will feel better about it all anyway.
- glangdale 7y ago
  Interesting story. Some design issues don't change! We were on Ethernet - old fashioned 10Mbs Ethernet (I think) with physical "taps" into a shared medium and terminators on the end. This is easy to remember as I recall the class doofus one day sitting there absently chucking an object up and down in his hand, while people angrily wondered why a whole string of Xterms weren't working. Duty programmer storms into the room and confiscates the item and plugs it in again. This same guy, a couple years later, manages to helpfully try to remove "." files from someone's directory while logged in as root, and manages to remove all of the honours students' home directories.
  - ddingus 7y ago
    One of my early networks was that kind. It is 10T. Roughly a megabyte per second. What a doofus! I made a few rookie mistakes, but none that basic and painful. Yeah, some things don't change. I have come to realize that is because people pretty much work the same way. Context changes, but the core doesn't.

ddingus 7y ago

I am just gonna ramble for a minute. Plz either indulge or ignore. I miss this stuff! Thanks. I would have loved to profile that little system. It's crazy how lean those older systems really were. A 30Mhz R4K could play MP3 files streamed via NFS. (90 percent CPU utilization, not headless, with local desktop logged in and active) I had one, at that clock useless by the time I got it, doing just that, because why not? After reading your comment, I realize I had a machine just playing a compressed audio file with the resources needed to serve 20 of you a useful computing environment! What kind of network were you on? Was it even ethernet? 10T? My first multi-user experience was horrible! It was on a 386/25, running Xenix and it had capacity for 16 users via either 19200 or 9600 baud SERIAL and VT100 terminals... I had 12 users at peak on that one, and most of them ran multi-user WordPerfect and some MRP thing, Symix, I think. I got the job because I read all the manuals. First sysadmin post and it was a pig. Learned a ton though! Enough to realize I could have a lot of fun on the better UNIXes, and scored a position working with SGI computers. (in that timeframe those computers with all the spiffy software so well engineered were like computing from the future, so much fun) Another time, while doing sysadmin on an SGI Irix multi-cpu Origin system serving some 30 users doing high end cad, I did some data logging. That system had 16GB Ram, 4 R12K CPU's with super fat caches, dual homed 1000T ethernet, BTW. I forget the clock. Probably 400Mhz I logged user activity every few seconds for roughly a week. This was an effort to see whether overall system speed was impacting productivity. I had a few users grumble during a peak time, so... Learned a few things: The system itself could perform near max capability when there were 4 concurrent user CAD demands. OS overhead was a few percent tops, in almost all circumstances. This was not in of itself any kind of issue. Irix ran pretty damn lean. Once in a blue moon, the system would page, but the Irix file caches are gold. This never really was an issue either. Maybe for a few minutes at a time during a serious push tops. A few times per week, usually on a Friday, they would max it out, and more than 4 concurrent, high demand sessions would be present. Deffo slowdown. Among the users, the average full compute demand was roughly 2 minutes. Some instances of this were longer for power users working on more substantial models. 5 to 10 minutes. These were sporadic, during the day. The reason was simple, and it was a model recompute. Happens as users roll up all their changes. Interestingly, light duty users, doing detail drawings, or minor model updates, sustaining engineering type stuff, they used the system heavy, perhaps 60 percent of their workday, but rarely hit peak single core compute for more than a few seconds at a time. Was hard to even see these. They did not really do big recomputes, but they did do the occasional big drawing render, and those were as bad as the power users. But not even daily. Most users hit the system both harder and less frequently. 20 to 30 percent of their day, but did post up regular ~2minute single core max compute demands. These people were working on sub systems, and would often copy one, modify, update, check it in, done, next. The power users hit the ~5 to 10 minute peak compute and used the system half the day. They were working at the entire product level. Big demands on RAM, CPU, Network. Multiple times daily. What I did was put local compute resources in front of the power users and restructure the network to give them a quieter, higher throughput subnet. There were a few of these users. They did became network bound, as the data transfer was significant compared to everyone else running on the main server, with high throughput disks. (15K RPM Cheetah drives) This impacted their get going times, but they only did that occasionally. Once things got cached locally, non issue overall. They adjusted how they work and marginalized it. The biggest saving was honestly to just keep it logged in, screen locked, etc... The rest of the users reported a significant speed up after these things were done. Now, here's the thing! A second data logging actually did show the power users improve. And they responded by burying those boxes, opening up a second session on the main one to continue. LOL, fine. It was good enough before, so I said nothing. They were power users and working at the product level and gains there paid off nicely in terms of total project capacity per year. No worries. There to help, blah, blah. But I did chuckle about them very rapidly figuring out how things worked. (They used the excellent virtual desktop feature in the 4dwm window manager common to SGI computers. One click and they were viewing their local session, one more click and they were viewing their remote one, next.) But everyone else demonstrated no real change! The data just was not there to support a big gain, and it totally was not there after the power users did their thing by running two sessions anyway. So, what was it? Turned out to be network. When I put the local compute where it needed to be, we moved some switches and had inadvertently improved load balancing at the physical layer. Some users, prior to this, were basically blocking others. Latency went down for everyone, and average throughput went up, and that proved to be the single most gratifying improvement for them, and it was just faster interactive response. No effective change in actual compute / time unit available, nor demanded from them. The parallels today are obvious. Get that page response time down. Effective throughput, what users can get done may bump up a little, but the vast majority won't do it. But, their feel, perception will ramp right up to the positive. This is true even when it comes at the expense of other things maybe being slower, taking longer. Just get them feedback NOW, and they will feel better about it all anyway.

glangdale 7y ago
Interesting story. Some design issues don't change! We were on Ethernet - old fashioned 10Mbs Ethernet (I think) with physical "taps" into a shared medium and terminators on the end. This is easy to remember as I recall the class doofus one day sitting there absently chucking an object up and down in his hand, while people angrily wondered why a whole string of Xterms weren't working. Duty programmer storms into the room and confiscates the item and plugs it in again. This same guy, a couple years later, manages to helpfully try to remove "." files from someone's directory while logged in as root, and manages to remove all of the honours students' home directories.
- ddingus 7y ago
  One of my early networks was that kind. It is 10T. Roughly a megabyte per second. What a doofus! I made a few rookie mistakes, but none that basic and painful. Yeah, some things don't change. I have come to realize that is because people pretty much work the same way. Context changes, but the core doesn't.