3 ms·

> For example, 36-bit physical addresses support 16GB memories ... and there already have been shipped single-rack microprocessor boxes with 16GB using just 16M

> For example, 36-bit physical addresses support 16GB memories ... and there already have been shipped single-rack microprocessor boxes with 16GB using just 16Mb DRAMs; there are of course, more in the 4GB-8GB range. Of course, a 32-bit physical addressing machine can get around this with extra external-mapping registers ... assuming one can ignore the moaning from the kernel programmers :-) I remember 16 megabytes of RAM being enough for a good gaming rig in 1995. Who was using gigabytes of RAM back then, and for what?

hackcasual 5y ago
Databases. Early high traffic internet services
- colejohnson66 5y ago
  I’m other words: the same things that, today, are using a terabyte of RAM. Cloud computing and databases.
monocasa 5y ago
A couple years later, but in 1997 you could get one of these with 64GB of RAM. https://en.wikipedia.org/wiki/Sun_Enterprise#Enterprise_10000 https://en.wikipedia.org/wiki/Sun_Enterprise#Enterprise_1000...
hnlmorg 5y ago
Most likely databases. Pretty sure one of the Sun SPARC boxes I managed in 1995 and that had a few GBs of RAM. It also ran Informix, which I don't miss administrating.
cesaref 5y ago
I was building and speccing servers to run banking applications in the mid to late 90s and this was in the days when x86 was still rubbish (or perceived to be so), so it was big Solaris boxes (E10k etc) and beefy HP PA-RISC machines. Applications were written in C++ and COBOL, the DB was Oracle. CPUs were expensive, disks were slow (and expensive - this is when EMC ruled!), so memory was used to boost database performance, and you could put a lot of memory in these machines (and we did). There were often 3 machines at each site, 2 production (one hot standby) and 1 test/qa machine, usually the same chassis but with lower specs (less CPU, less memory, less disk etc). The production machines were often at two close sites (10k apart) with disk replication between them over fibre in the street. It was quite common back then for the clients to specify ridiculous projected growth, and require total resilience from the hardware. I'd spec up the machines, and they'd baulk at the price (and when you get an international bank to baulk at the price you can imagine we're talking multiple millions for hardware let alone support contracts etc). Then, following a slice of realism, they'd relax some of the requirements, and we'd get something for 1/4 of the money. Happy days, lots of travel though.
- contingencies 5y ago
  How did they secure the fiber? IIRC back then it was hard to get decent (especially non-backdoored) hardware encryption solutions @ high network throughput. I wonder if anyone spliced fiber, MITM'd disk replication, made bank and got away with it...
  - cesaref 5y ago
    I would be very surprised if there was any encryption, but I don't know how the tech worked, other than it was all 'dark fibre', that is, purchased links between sites without any offered services. The EMC drive arrays were expensive enough that they'd be shared between projects, effectively, capacity was 'leased' to different teams within the organisation. Those drives were replicated between the sites via the fibre, so the infrastructure team responsible for that would have been doing whatever they could I guess (probably getting it working at all was the challenge rather than worrying about encryption). I do know that exchange connectivity for trading was via leased X.25 connections over the PSTN, and there was no encryption on those links. The client orders were small though, nothing to get excited about. Proper inter-bank stuff, the big bucks, were carried on the SWIFT network, which is encrypted, and that would be the place to attack if you wanted to get up to mischief. I guess that's still used today (was heavily used last time I worked in that industry 10 years ago for settlement, fx, etc)
    - contingencies 5y ago
      IMHO the most interesting thing about SWIFT (whose official line is that they are just a messaging service and carry no money) is that it is an effective global monopoly on international inter-bank financial transfers with no published history. What backstory is available shows that it was founded by a European as a Belgian cooperative who was sent back to Europe after being head of international settlements at Amex. The organization appeared really suddenly given glacial technological norms of the day, and its first HQ was not located in a financial center but rather in Virginia, right by the CIA. Yes, I'm saying it was probably founded as an intelligence asset. The US really leveraged the post-WWII and cold war periods to cement its geopolitical dominance globally. Well played.
therealcamino 5y ago
In 1996 electronic design automation tools were also hitting the limits of 32 bit address spaces. I don't remember the exact timing of when they were able to use more than 4GB in a single process; I think there might have been an in-between period where a Solaris machine running on a 64 bit SPARC CPU could use more than >4GB, but a single process was limited to that amount. Within a few years the tools were ported to use more than 4GB in a single process.

hackcasual 5y ago

Databases. Early high traffic internet services

colejohnson66 5y ago
I’m other words: the same things that, today, are using a terabyte of RAM. Cloud computing and databases.

monocasa 5y ago

A couple years later, but in 1997 you could get one of these with 64GB of RAM. https://en.wikipedia.org/wiki/Sun_Enterprise#Enterprise_10000 https://en.wikipedia.org/wiki/Sun_Enterprise#Enterprise_1000...

hnlmorg 5y ago

Most likely databases. Pretty sure one of the Sun SPARC boxes I managed in 1995 and that had a few GBs of RAM. It also ran Informix, which I don't miss administrating.

cesaref 5y ago

I was building and speccing servers to run banking applications in the mid to late 90s and this was in the days when x86 was still rubbish (or perceived to be so), so it was big Solaris boxes (E10k etc) and beefy HP PA-RISC machines. Applications were written in C++ and COBOL, the DB was Oracle. CPUs were expensive, disks were slow (and expensive - this is when EMC ruled!), so memory was used to boost database performance, and you could put a lot of memory in these machines (and we did). There were often 3 machines at each site, 2 production (one hot standby) and 1 test/qa machine, usually the same chassis but with lower specs (less CPU, less memory, less disk etc). The production machines were often at two close sites (10k apart) with disk replication between them over fibre in the street. It was quite common back then for the clients to specify ridiculous projected growth, and require total resilience from the hardware. I'd spec up the machines, and they'd baulk at the price (and when you get an international bank to baulk at the price you can imagine we're talking multiple millions for hardware let alone support contracts etc). Then, following a slice of realism, they'd relax some of the requirements, and we'd get something for 1/4 of the money. Happy days, lots of travel though.

contingencies 5y ago
How did they secure the fiber? IIRC back then it was hard to get decent (especially non-backdoored) hardware encryption solutions @ high network throughput. I wonder if anyone spliced fiber, MITM'd disk replication, made bank and got away with it...
- cesaref 5y ago
  I would be very surprised if there was any encryption, but I don't know how the tech worked, other than it was all 'dark fibre', that is, purchased links between sites without any offered services. The EMC drive arrays were expensive enough that they'd be shared between projects, effectively, capacity was 'leased' to different teams within the organisation. Those drives were replicated between the sites via the fibre, so the infrastructure team responsible for that would have been doing whatever they could I guess (probably getting it working at all was the challenge rather than worrying about encryption). I do know that exchange connectivity for trading was via leased X.25 connections over the PSTN, and there was no encryption on those links. The client orders were small though, nothing to get excited about. Proper inter-bank stuff, the big bucks, were carried on the SWIFT network, which is encrypted, and that would be the place to attack if you wanted to get up to mischief. I guess that's still used today (was heavily used last time I worked in that industry 10 years ago for settlement, fx, etc)
  - contingencies 5y ago
    IMHO the most interesting thing about SWIFT (whose official line is that they are just a messaging service and carry no money) is that it is an effective global monopoly on international inter-bank financial transfers with no published history. What backstory is available shows that it was founded by a European as a Belgian cooperative who was sent back to Europe after being head of international settlements at Amex. The organization appeared really suddenly given glacial technological norms of the day, and its first HQ was not located in a financial center but rather in Virginia, right by the CIA. Yes, I'm saying it was probably founded as an intelligence asset. The US really leveraged the post-WWII and cold war periods to cement its geopolitical dominance globally. Well played.

therealcamino 5y ago

In 1996 electronic design automation tools were also hitting the limits of 32 bit address spaces. I don't remember the exact timing of when they were able to use more than 4GB in a single process; I think there might have been an in-between period where a Solaris machine running on a 64 bit SPARC CPU could use more than >4GB, but a single process was limited to that amount. Within a few years the tools were ported to use more than 4GB in a single process.