Ontopic Random Computer-Electronics Thread

While true, unless you're manipulating huge files, it doesn't matter. The next jump after NVMe will be huge too.

ITS 50% FASTER, SO WINDOWS NOW BOOTS IN .2 SECONDS RATHER THAN .4!!!1111
The difference matters more if you're manipulating a whole lot of different files simultaneously at once. You know, like multitasking on a modern machine with a lot of cores/threads.

Every time a SATA SSD reads a block, a single CPU interrupt fires and the driver servicing that interrupt has to interrogate the AHCI host adapter, figure out which entry in the queue the drive is returning, figure out which process on the machine wanted that data, then talk to the AHCI controller AGAIN so the controller can DMA the data where it needs to go... so that a second interrupt can fire when that data transfer completes. And the AHCI queue is only 32 entries deep so odds are there's also a software managed I/O queue on top of that that the driver also handling as well, so it has to read the next request from the queue and then add that to the drive queue.

This didn't matter so much when we were using spinning rust drives with slow seek times, but on a modern machine with lots of cores simultaneously fighting over data, and SATA SSDs having far less access latency, the software/AHCI funnel becomes the next bottleneck.

NVMe gets rid of that funnel. A drive has 64K independent queues with 64K queue entries itself. Each task on the machine can be given its own path into the NVMe drive, and can read/write from the drive completely independently of any other thing going on.

There's still some overhead setting up and tearing down queues, but it's far less overhead. It's analogous to a process having to call malloc() once to get some RAM, then it can do whatever it wants with the RAM. Yeah there's still malloc()/free() overhead, but at least the actual act of reading/writing memory doesn't have to pass through a central driver anymore.

And I don't measure this shit by how quick Windows boots, I measure this shit by doing things like iteratively processing centuries worth of underwater recordings on a 16-core/32-thread Xeon server and profiling what parts are running fast and slow. Staging files on NVMe for processing has greatly sped things up.
 
  • Love
Reactions: wetwillie
i notice the difference.
You weren't exactly growing gray hairs waiting for SSDs to complete I/O ops.

If you've got enough different threads of I/O going that it makes a difference... bully for you, I guess. There's a lot of momentum in compiler design to optimize for single threaded I/O performance still, since the vast majority of the time, a single app will be reading or writing a single file at a time.
 
  • Gravy
Reactions: wetwillie
My point stays the same. None of that really matters to home users like everyone here. At work, sure.
I would notice when doing recording work and running lots of effects on the fly. Currently spinning SAS rust.

My coding/web/photography machine? - the time to install the drive would probably take 2-3 years to pay off in time saved. NeVaMe
 
  • Haha
Reactions: Jehannum
I would notice when doing recording work and running lots of effects on the fly. Currently spinning SAS rust.

My coding/web/photography machine? - the time to install the drive would probably take 2-3 years to pay off in time saved. NeVaMe
We were doing expansion-chassis, non-RAID SCSI I/O disk-based recording way back in the early 1990s. Got 48 channels, audio isn't exactly heavy I/O load.

Effects load up the processor, not the disk. ProTools 3 had an expansion chassis that contained DSP cards to offload the processing from the PowerPC 601 at its blistering 100MHz.
 
  • Gravy
Reactions: wetwillie
We were doing expansion-chassis, non-RAID SCSI I/O disk-based recording way back in the early 1990s. Got 48 channels, audio isn't exactly heavy I/O load.

Effects load up the processor, not the disk. ProTools 3 had an expansion chassis that contained DSP cards to offload the processing from the PowerPC 601 at its blistering 100MHz.
I'm using ProTools 10, 16 channels via Firewire. PLug-in effects appear to result in a lot of drive accesses when going in/out along a timeline. That said, the setup has yet to choke on me during recording or post-processing. Allen & Heath ZED16R board. And no RAID, just one 1 TB SAS for the system, same for recording, 128 GB of fast memory(don't ask, my memory fails me, what ever was cool//fast at time). meh. Good topic.
 
I'm using ProTools 10, 16 channels via Firewire. PLug-in effects appear to result in a lot of drive accesses when going in/out along a timeline. That said, the setup has yet to choke on me during recording or post-processing. Allen & Heath ZED16R board. And no RAID, just one 1 TB SAS for the system, same for recording, 128 GB of fast memory(don't ask, my memory fails me, what ever was cool//fast at time). meh. Good topic.
I mean, you can say it "appears to be" whatever you like. It could "appear to be" tachyon emissions from the head lodged up your butt, but it's not I/O load.
 
  • Haha
  • Gravy
Reactions: fly and wetwillie
You weren't exactly growing gray hairs waiting for SSDs to complete I/O ops.

If you've got enough different threads of I/O going that it makes a difference... bully for you, I guess. There's a lot of momentum in compiler design to optimize for single threaded I/O performance still, since the vast majority of the time, a single app will be reading or writing a single file at a time.
Just gotta teach more people to use pthreads. That's how I make a huge mess of things.
 
  • Gravy
  • Haha
Reactions: Domon and Jehannum
And in unrelated news, my work laptop decided to push in a new BIOS update, which in turn attempted to update the firmware in my thunderbolt dock, and it bricked my dock.

Googling "TB16 bricked" seems to indicate this is a real common problem, and it's caused by shit like having Bitlocker turned on (huh?) or by attempting to update the dock without having both the laptop and the dock powered from separate AC adapters, even though the damn dock powers the laptop anyway...

And now I'm spending the day working with 1 laptop screen and 1 monitor, which have different resolutions and everything, and it's tripping 100 kinds of OCD that I didn't know I had.

Dell's replacing the dock but I won't have it for another week :/
 
At 32 bits of depth, sampled at 48KHz, a single track of audio reads at about 188KB/s from disk. 16 of 'em is a tonce under 3MB/s. Nothing that hasn't been available from decent hard disks for the last, oh, 15 years.

up it to 96KHz, and you'll need a MIND BENDING 6MB/s.
Hey, I worry. Peace
 
Got that older Mikrotik 2011RM up and running to replace my FIOS router. A firmware upgrade and factory reset, then reinit of basic security rules with fasttrack solved the throughput issue. It now can max out my 400/400 connection.

It is not nicely interoperable with the Unifi APs though. For some unknown reason, any wireless client behind the AP wont be able to pull a DHCP address on a fairly regular basis. I think this is actually a unifi problem, not a mikrotik problem to be honest. I temporarily solved it by just putting long-ass leases on all the clients when it was working. When it was at 10 minute leases, about 40% of clients couldnt pull a new lease on a regular basis. I set it to 1600 minute leases :p

Which honestly, for a home network with fixed devices is fine.
What UniFi firmware? There's known DHCP issues with pretty much any version higher than 4.3.20.
 
What UniFi firmware? There's known DHCP issues with pretty much any version higher than 4.3.20.
yeah, im on all the latest firmwares... because fuck me, one would figure that a company would release stable and reliable and secure firmwares newer than a year or two old.

The UAP-AC-M is 4.3.28.11361 and UAP-AC-LR is 5.43.436
 
yeah, im on all the latest firmwares... because fuck me, one would figure that a company would release stable and reliable and secure firmwares newer than a year or two old.

The UAP-AC-M is 4.3.28.11361 and UAP-AC-LR is 5.43.436
Downgrade and I bet your DHCP issues will go away. UBNT is UBNT. Cheap for a reason. When it works, don't fuck with it, don't upgrade it, don't look at it wrong.
 
  • Gravy
Reactions: Jehannum
Downgrade and I bet your DHCP issues will go away. UBNT is UBNT. Cheap for a reason. When it works, don't fuck with it, don't upgrade it, don't look at it wrong.
Never understood the "gotta have the latest firmware" notion. If it works passingly well, don't fuck with it.
 
Downgrade and I bet your DHCP issues will go away. UBNT is UBNT. Cheap for a reason. When it works, don't fuck with it, don't upgrade it, don't look at it wrong.
yeah, my mikrotik stuff has been flawless and dead stable. UBNT is seeming more and more like the Apple of the networking world. Shiny and closed ecosystem.