3 ms·

I have a tangential question on this part: > I sometimes experienced severe system slowdowns due to high I/O, even if the data to be processed was not read/wri

by AnonHP 5y ago

I have a tangential question on this part: > I sometimes experienced severe system slowdowns due to high I/O, even if the data to be processed was not read/write dependent. On FreeBSD this does not happen, and if something is blocking, it blocks THAT operation, not the rest of the system. I’ve seen this for a long time in Windows, where any prolonged I/O brings the entire system down to its knees. But it also seems to affect macOS (which is based on FreeBSD) as a system, though it’s not as bad as on Windows. Has Windows improved on this over the years? I’m unable to tell.

philliphaydon 5y ago
I have no idea how operating systems work, but at a wild guess. If you're running the OS off the same disk thats threashing the io, and, its queued too many read/write operations to handle the reads for the OS? And maybe FreeBSD is just so small it effectively caches itself into memory and doesn't need the IO so it appears to function still? Curious to know the reason.
- philliphaydon 5y ago
  I guess based on the downvotes I’m wrong but they also don’t know? Reason I want to know is when I tried running ubuntu off a spinning disk and wanted to move some games to the drive it would transfer about 1gb then lock up. Didn’t happen with an SSD.
  - loeg 5y ago
    Yeah, in general wild speculation (especially if it happens to be incorrect, as it is in this case) is discouraged on this forum.
bopbeepboop 5y ago
yehNonsense0 5y ago
It’s either the disk is the bottleneck or the GUI process taking a back seat to the OS prioritizing the “real work” requested. Computers get faster, we throw more at them. Physics is still the law of the land. Truh truh truh trade offfss; in computer eng; truh truh truh trade offs sorry Bowie
formerly_proven 5y ago
Windows seems to rely on disk accesses in a lot of critical processes which is why it tends to have GUI lockups and slowdowns under I/O load. Even opening task manager, or just switching tabs in it, while the system is loaded can take a few seconds (~dozens to hundreds of billions of cycles).
detaro 5y ago
> macOS (which is based on FreeBSD) That's somewhat overstated, so I wouldn't draw such conclusions. (https://wiki.freebsd.org/Myths https://wiki.freebsd.org/Myths )
- bastardoperator 5y ago
  The funny part about this is I actually end up installing a lot of the GNU tools so I can have some level of parity when writing (mostly shell) code on MacOS.
- toast0 5y ago
  Adding onto this; the parts of the kernel that were from FreeBSD were taken two decades ago, without much if any attempt to follow up and rebase. I don't know about the disk I/O subsystem, or even if it was taken from FreeBSD, but the 2000 era FreeBSD tcp was scalable for 2000 era machines (although it would have been nice if Apple had taken it after syncache/syncookies), but needs changes from the 2010s to work well with modern machines. I'm sure that similar improvements have happened for disk I/O, but I just don't know the details. Not a lot of people would run a FreeBSD 4.x kernel today, but that's what's happening with the FreeBSD derived kernel bits in Mac OS.

by AnonHP 5y ago

philliphaydon 5y ago

I have no idea how operating systems work, but at a wild guess. If you're running the OS off the same disk thats threashing the io, and, its queued too many read/write operations to handle the reads for the OS? And maybe FreeBSD is just so small it effectively caches itself into memory and doesn't need the IO so it appears to function still? Curious to know the reason.

philliphaydon 5y ago
I guess based on the downvotes I’m wrong but they also don’t know? Reason I want to know is when I tried running ubuntu off a spinning disk and wanted to move some games to the drive it would transfer about 1gb then lock up. Didn’t happen with an SSD.
- loeg 5y ago
  Yeah, in general wild speculation (especially if it happens to be incorrect, as it is in this case) is discouraged on this forum.

bopbeepboop 5y ago

yehNonsense0 5y ago

It’s either the disk is the bottleneck or the GUI process taking a back seat to the OS prioritizing the “real work” requested. Computers get faster, we throw more at them. Physics is still the law of the land. Truh truh truh trade offfss; in computer eng; truh truh truh trade offs sorry Bowie

formerly_proven 5y ago

Windows seems to rely on disk accesses in a lot of critical processes which is why it tends to have GUI lockups and slowdowns under I/O load. Even opening task manager, or just switching tabs in it, while the system is loaded can take a few seconds (~dozens to hundreds of billions of cycles).

detaro 5y ago

> macOS (which is based on FreeBSD) That's somewhat overstated, so I wouldn't draw such conclusions. (https://wiki.freebsd.org/Myths https://wiki.freebsd.org/Myths )

bastardoperator 5y ago
The funny part about this is I actually end up installing a lot of the GNU tools so I can have some level of parity when writing (mostly shell) code on MacOS.
toast0 5y ago
Adding onto this; the parts of the kernel that were from FreeBSD were taken two decades ago, without much if any attempt to follow up and rebase. I don't know about the disk I/O subsystem, or even if it was taken from FreeBSD, but the 2000 era FreeBSD tcp was scalable for 2000 era machines (although it would have been nice if Apple had taken it after syncache/syncookies), but needs changes from the 2010s to work well with modern machines. I'm sure that similar improvements have happened for disk I/O, but I just don't know the details. Not a lot of people would run a FreeBSD 4.x kernel today, but that's what's happening with the FreeBSD derived kernel bits in Mac OS.