Windows is poor when performing disc i/o - ReactOS too?

[dizt3mp3r]

An observation:

With Windows NT5 or NT6, I have noticed that responsiveness is severely reduced when any high volumes of disc access are being made through a drive search using a tool such as "Effective file Search" or Windows in-built search functionality. This decrease in responsiveness affects any tool that attempts to perform any file or folder i/o at the same time. The result is a often a complete hang of resources competing for i/o and sometimes it can lead to a hang of the whole Explorer GUI. Given that the explorer is in effect the whole interface to Windows then a high i/o operation can take Windows out altogether.

This deterioration used to be especially marked on XP when writing CDs through the slower CD IDE bus. Whilst the CD was being written/finalised the system was basically unusable. If the CD writing failed for some reason the explorer GUI would sometimes be unrecoverable, requiring the explorer process to be killed/restarted.

It seemed as if all disc i/o was in pact serialised rather than being in parallel and it further seemed that Windows cpapabilities in sharing any parallelised disc i/o was very, very poorly implemented. No apparent scheduling of i/o.

I know that hardware has a hand in this i/o rate but given that the in-built controller technology should be optimised for fast i/o and the drives are so fast these days it always seemed strange that Windows still seems to handle i/o so badly. If the drives and bus i/o are so fast why do I still experience drasstic slow-downs when using Windows? Bear in mind this is the same experience with XP, Vista 32 bit and Windows 7 64 bit and on a variety of hardware, Acer, Dell &c including some fast hybrid drives.

Can't say I have yet experienced it on Win 10 as I don't have a win10 machine currently (the brand-new swine of a Dell laptop died on me).

OK, this is Windows I am talking about and not ReactOS but it is still relevant. So, why am I raising it here? I am hoping that this is one area where ReactOS is implemented more efficiently than Windows, some sort of efficient scheduler allowing time-slice-access to i/o resources rather than dumping all i/o requests to the hardware in a serial fashion and hoping for the best. This is one area where in my limited experience ReactOS could improve on Windows.

In fact I am thinking of starting a new thread where we propose improvements within ReactOS that take us to functionality beyond that of Windows. Locations and places where we find Windows deficient or lacking by design.

For example the wireless stack - but that is for another post...

[Adcock]

In fact I am thinking of starting a new
thread where we propose
improvements within ReactOS that
take us to functionality beyond that of
Windows. Locations and places where
we find Windows deficient or lacking
by design.

First of all what is a thread?
I am assuming that it is a new topic and then that is a nice idea.
Why didn't you create it already?
Now i/o problem:
I don't write cd/dvd much. So not much idea.
One reason for this problem could be that Microsoft do not develop important things for Windows beyond Windows itself.
Because if they do then commercial counterparts will become useless and those companies might choose to abandon Windows.
Then Windows platform has a chance of losing market.
However your problem needs to be verified by others.
Lets see if they agree.

[val]

dizt3mp3r,
1) your ideas and conclusions about Windows I/O (disk in particluar) are wrong. reading them it readily becomes obvious that you have no idea what you are talking about. maybe try to learn the topic if you are interested. shotgunning new topics is cool, education is better.
Just to not make such silly statements as below:

It seemed as if all disc i/o was in pact serialised rather than being in parallel and it further seemed that Windows cpapabilities in sharing any parallelised disc i/o was very, very poorly implemented. No apparent scheduling of i/o.
...
CD IDE bus.

Yes, you heard terms "bus", "i/o", "scheduling i/o" etc. But that is not sufficient to make such conclusions. "very poorly implemented"... come on! of course they "poorly implemented" the thing you have fantasized.

2) I used the built in search and burnt CD/DVDs on XP and 7, Never saw hangs. What I did wrong?

The reasons of what you depicted might be any: burning utilities behave erratically, buggy driver (for example I've experienced recently hangs caused by the infamous Intel's AHCI driver IaStor.sys), stupid "extensions" hanging on Explorer, finally you could do something stupid. Windows I/O has nothing to do with all these.
Of course, you are aware that unlike HDD/SSD/USB mass storage devices etc, CD/DVD are written as a whole. You cannot write it from two or more initiators simultaneously. Writing utility should lock the whole disk. It's the nature of these media. In no way this should hang the GUI shell or anything. And it doesn't. Your particular case had to be investigated by examining your setup, event logs.

[dizt3mp3r]

Val you can be close to idiotic in your near-insulting replies. You've done it before and you'll do it again.

I know what I am talking about as it is the experience I have encountered. I am also a sys admin for years so I am not even going to justify myself by talking to you. As you said, my observation is that Windows i/o is badly implemented which leads to slow-downs in general affecting explorer. This has been apparent in many different types of hardware and on versions of Windows.

This experience is here for discussion and not for you to insult anyone - again and again.

So, ignoring you from this point on will make me quite happy.

With regard to Windows on servers, my experience here is comprehensive and I have not noted slow-downs of the type I have described as those systems have always been over-specified with regard to number of discs, type of discs, large drives optimised to contain few files placed on the outer edge of the disc to reduce seek times, raid 0 striped systems, large number of cores, lots of ram &c. These systems operate as expected as they take advantage of high specification hardware. It is only in the typical laptop/desktop systems of let us say 2.5ghz, 2-4 cores, 800mhz bus speeds and 4-8gb ram, one or two drives on a IDE or SATA bus, drives 50-70% full, where this i/o degradation has typically occurred.

As to why, it has not been easy to diagnose except to ascribe the problem to the i/o subsystem, drivers all up to date, PIO set, there's not much to configure with regard to drives as they are normally plug and play. Drives not fragmented, no obvious bottlenecks, no other i/o contention until I start a subsequent process opening some files on the drive, then the contention occurs. Fast-ish drives with space to spare. Perfmon shows reasonable i/o rates. System logs show no system nor application errors, I understand disc i/o and queue lengths and while the latter is hard to extract from WMI I'd assume that these would be high during the period as the degradation implies high queue lengths. On the VMS systems I previously maintained storage controllers handled the i/o from the o/s ensuring queue lengths were minimised and i/o bottlenecks were reduced. I suppose I just have expectations that i/o is handled today better than it used to be in the late 90s. Perhaps I am wrong. I am just surprised that is still happens today.

In any case the tight integration between explorer and windows GUI is understood and any degradation to the GUI whilst explorer is attempting to perform an i/o function is also equally well-known. It isn't just me that has experienced this...the limitation is well known.

I have always preferred the concept of a discrete file manager that can run independently of the GUI but that isn't the way that explorer is built.

I'd love to hear that this problem is unheard of in Win10 regardless of hardware, that would give me a solid and good reason to upgrade this system. Most of all though I'd like to hear that the ReactOS i/o subsystem is going to be better than that of Windows. So far, my understanding is that ReactOS may well be quicker across the board...

[EmuandCo]

Noone insults anyone here, except me! SO cool down or I make you cool down for a while...
There's not much to optimize if you use a normal HDD which seeks around everywhere on the HDD when you start to do multi tasking I/O jobs. So this has nothing to do with poor implementation at all. Just use modern hardware and in this case SSDs.
Ah and btw... did I just read RAID 0 and sys admin in one post? With a good reason I hope.

[val]

oh, boi.

I'd love to hear that this problem is unheard of in Win10

It's unheard on the prevoius versions too.
You don't know what hangs your GUI (if it does) and don't want to know.
Rather, you keep make yourself a laughingstock creating silly topics here nobody will be taking seriously.

It's not insulting at all, I just said how it is - the guy has no idea what he is talking about. Note I didn't call him "idiotic". Didn't I?

[EmuandCo]

Pushing all his sentences ad absurdum is insulting too.

[dizt3mp3r]

I can't stand talking to Val, he knows just the right levels to be insulting and then to pretend he didn't really mean it. He's on ignore for that reason. I hope his last post was better quality than the first. He adds very little to any discussion other than to start a flame war.

id I just read RAID 0 and sys admin in one post? With a good reason I hope.

Oh yes, on the VMS systems we run/still encounter, we have/had raid 0 (striping) for speed and then volume shadowing for temporary redundancy. It didn't do much more than replicate any data errors to the second set but it made the clients happy.

[Adcock]

You don't know what hangs your GUI (if it does) and don't want to know.

Hi val
I also don't know.
But I would like to learn from someone who already knows.
Please do tell.
Is it because Windows XP uses a stacking window manager?
Is ReactOS window manager a stacking window manager?
If ReactOS window manager is a stacking window manager then please fix this problem.
Stacking window manager

A well-known disadvantage of
stacking is that when windows are
painted over each other, they
actually end up erasing the
previous contents of whatever part
of the screen they are covering.
Those windows must be redrawn
when they are brought to the
foreground, or when visible parts of
them change.

How can I verify that ReactOS doesn't have this issue?
Help.

[Harteex]

I've also always felt that the overall performance suffers a lot during heavy IO on Windows. Why that is, I don't know. Haven't noticed the same on Linux.

[Konata]

I've also always felt that the overall performance suffers a lot during heavy IO on Windows. Why that is, I don't know. Haven't noticed the same on Linux.

I don't know the technical details, but I'm pretty sure Windows organizes I/O so it works better with the rest of the system. It's just observation, but I've noticed in Windows, if I'm moving a large file, the rest of the system still works. If I move a large file in Linux, the system is completely unresponsive, I can't even open programs when doing that.

[dizt3mp3r]

I don't know the technical details, but I'm pretty sure Windows organizes I/O so it works better with the rest of the system. It's just observation, but I've noticed in Windows, if I'm moving a large file, the rest of the system still works. If I move a large file in Linux, the system is completely unresponsive, I can't even open programs when doing that.

I wish my experience was the same but typically it is the other way round but that is just my experience. I am quite prepared to put it down to an unlucky bad hardware mix (or budget hardware perhaps) but my hardware has varied over time and the problem has always been present more or less.

It feels as if the i/o is serialised and if you have a massive task running then your simple i/o task gets put in the end of the queue and does not get any hardware visibility until the current massive task has completed. My impression was that storage controllers were there to help optimise or share out the disc resource requests in a more parallel fashion and if they are doing their job then it seems that disc i/o is restricted by Windows apportioning i/o requests synchronously otherwise the simple i/o tasks would get a little disc access and then complete. Something is restricting access if the disc isn't being thrashed and it feels like a synchronous FIFO pipe of some sort.

If the cpu was being apportioned in the same manner you'd have large processes that hog the cpu preventing small process from having any cpu time until the large jobs complete. We wouldn't accept that for cpu scheduling, my suggestion is that ReactOS tries to be more clever than Windows in this one respect but I don't know if this is feasible or even possible. I'm still unsure as to what the issue really is.

Please remember it was just an observation but it is very useful to hear other's experiences.

[val]

You don't know what hangs your GUI (if it does) and don't want to know.

Hi val
I also don't know.
But I would like to learn from someone who already knows.

Are you asking me why dizt3mp3r's computers hang, when he burns CDs and searches for something on them? Sorry, my crystal ball is temporarily unavailable. I even am not sure that thing is a real thing and not just yet another quirk in their Love And Hate Story. Windows and dizt3mp3r.

As I've said. Recently after repair and some upgrade and reconfiguration, my computer started to hang. On resuming from standby. On switching between users. And finally it flew out into bugchecks.
What I did. I missed info about the driver on the blue screen itself, so I looked at the minidump file and saw - the culprit was IaStor,sys. Yup. I wanted to finally take advantage of AHCI on this machine. Forced to switch back from AHCI to IDE on 6 of 8 ports, now I were not getting these hang outs. Other two ports were left in AHCI mode but on another controller (jmicron's). Unfortunately here, the very similar behavior showed up eventually. Just with different bug checks and the hang outs appear at random times now but rarer. Among them Windows reported impossibility to finish delayed writes on the C: volume. That was the clear sign, - this AHCI driver as well cannot deal with its duties. After disabling AHCI completely, everything got back to the normal operation.
It just happens. A good technology gets a poor implementation and could not be used.
For what this story is mentioned here? For this - if I encounter an obviously inappropriate operation of the computer, the first thoughts are - something just isn't right (configured, set up, installed etc). it has to be figured out. I am not starting extremely incompetent ranting claiming "i/o scheduling is very poorly implemented". Boy, not that far, the reason is probably much closer to the surface.

Please do tell.
Is it because Windows XP uses a stacking window manager?
Is ReactOS window manager a stacking window manager?
If ReactOS window manager is a stacking window manager then please fix this problem.
Stacking window manager

How can I verify that ReactOS doesn't have this issue?
Help.

No it's not because of this for sure. And for me, XP's graphical system looks faster and more efficient than of later versions. But I like that glassy look too tbh. I had no doubt this quote is from Wikipedia. It is extremely anti-Windows. That bias just stinks there. all that blablabla about is not worth of attention. their favs didn't manage to get close even on a fraction to the XP graphical subsystem. in trems of usability, nice look and performance. linux gui is ugly and it literally constantly loads CPU. they invented 1000 windows managers, layout engines, composers and compositors. gave them a million names. but performance as was sucky 20 years ago as remains there now.

Graphics interfering with disk I/O... Just think about it - how on the planet graphical stuff could interfere with disk operations? On a multiprocessor system, with exteremely fast interfaces like PCIe, with things as DMA, dedicated GPU memory, with a heavily multithreaded reentrant OS whose I/O is asynchronous and interrupt handling particularly and overall I/O handling is that complex and developed. it's all polished in years to run fastest. On both sides - hardware and OS design. That's why I recommended dizt3mp3r to first read about that I/O handling prior to make statements about its implementation quality.
Just look at CPU usage on Windows when performing "heavy I/O". See, it's negligible. What exhaustion or contention?! Where? On which point? PCIe? Maybe SDRAM? CPU-North bridge interconnect? you have multiple storage ports, often multiple controllers. they are independent and don't interfere. that's why you could speed up everything which might take advantage of that parallelism. Like paging. You place two pagefiles on two separate disks and paging speed doubles. Or RAID setups. Anything that is parallelizable with respect to storage. Making conclusions about "inefficent I/O scheduling" based on GUI hang out, it's just unwise.
If some GUI hangs on waiting for a slow operation like storage access, this is because developers of those applications did mistakes somewhere and put GUI stuff and storage access stuff in the same thread. For example an Explorer window hangs waiting non-existent floppy drive if you were unlucky to accidentally click that A: drive icon. Or sometimes on network operations. Firefox as well has such an "option" in some circumstances.
This is mostly flaws in the applications' design.

[dizt3mp3r]

I do hope Val's last post was a little more positive than his previous. It is always nice to talk to positive types.

[ROCKNROLLKID]

I do hope Val's last post was a little more positive than his previous. It is always nice to talk to positive types.

Don't feed the troll mate.