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

Here you can discuss ReactOS related topics.

Moderator: Moderator Team

User avatar
EmuandCo
Developer
Posts: 4723
Joined: Sun Nov 28, 2004 7:52 pm
Location: Germany, Bavaria, Steinfeld
Contact:

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

Post by EmuandCo »

OK, enough! 7 days holidays for val!
ReactOS is still in alpha stage, meaning it is not feature-complete and is recommended only for evaluation and testing purposes.

If my post/reply offends or insults you, be sure that you know what sarcasm is...
justincase
Posts: 441
Joined: Sat Nov 15, 2008 4:13 pm

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

Post by justincase »

So, can we get back to the topic at hand?
While val used a rather offensive approach, some points may have been valid ( ;) ), specifically that no matter how clogged up your disk i/o gets, the GUI shouldn't hang unless for some reason either the GUI and disk i/o are running in the same thread or the GUI thread is blocking while waiting for (one of the) i/o thread(s) to return.

So if we take dizt3mp3r's question without the specific parts about i/o scheduling and whatnot, it might look more like this.

"The Windows GUI (provided by explorer.exe) has a tendency to freeze up for me when I'm copying/moving several files at once. It seems to me like a better implementation of explorer.exe could avoid this. Is this accurate? Can ReactOS be better than Windows in this regard? Is it already? If not, what would be necessary to make ReactOS' explorer.exe handle such situations better than Windows' explorer.exe currently does?"
I reserve the right to ignore any portion of any post if I deem it not constructive or likely to cause the discussion to degenerate.
User avatar
dizt3mp3r
Posts: 1874
Joined: Mon Jun 14, 2010 5:54 pm

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

Post by dizt3mp3r »

I still haven't read Val's post so I can't comment specifically. The trouble is not with Val's technical competence, we expect people here to have at least some of that. It is just that he sometimes has an appalling way of expressing himself, seems to be unable to listen to others and distilling what potentially might be happening and then giving useful feedback without being insulting. He also holds a grudge - clearly. Ah yes, that's a troll defined. Don't feed 'em is what the man said. I'll try not to.

Back to the issue, I assume Val is pointing it out as a GUI slowdown, well in the case I was describing it wasn't just the GUI, though that is one aspect where Explorer's all-encompassing nature is affected adversely by file moves/copying &c. Explorer's weaknesses are well known and slow-downs in the GUI occur when Explorer does a lot of i/o. I've heard tell that in Vista+ it was wise to minimise the copy dialog window as the copy-in-progress animation used significant resources that were better spent by the CPU in organising the copy operation. I know you can use 3rd party copy/delete/move tools to minimise the impact of explorer degradation. The problem I was describing was encountered when using such a tool.

The issue I was described was not GUI related. Other applications expecting simple access to i/o seem to slow disproportionately (perhaps just running a program that reads the contents of a folder to extract filenames) when a task such as a folder search is being carried out simultaneously by another application, not an explorer search but say using Effective File Search. The two i/o tasks are competing for resource, ie disc access - that much is understood so I would simply expect the first task to slow down a little but instead the first task may hang completely until the Effective File Search is complete or killed. The first task does not get a look in and i/o seems to be serialised. This might be more apparent on older hardware where the hardware fails to compensate. The machine I most recently tested this on used a SATA 2 3gb/s bus.

With regard to the GUI, I agree that it would be very nice to de-couple file manager windows from the background generation, the taskbar, the overall command of the GUI but that is probably not practical given that ReactOS aims to replicate windows functionality. It will probably have to remain the same in essence. Perhaps it might be possible to spawn new explorer processes that exist solely in their own right that can carry out some tasks and be killed without bringing down the whole GUI (as later versions of explorer seem to do). Those are side issues for me as it is the serialisation of i/o that is the issue I am trying to highlight.

I am assuming (correctly or incorrectly) that the o/s has some underlying methods of talking to a hardware abstraction layer that includes multiple i/o channels that the o/s utilises efficiently. My observation was that this doesn't seem to be working as well on Windows as it might. I appreciate that asynchronous i/o is more expensive in cpu cycles than synchronous i/o and perhaps there is something that can be improved here in ReactOS in relation to Windows. I am just guessing. If the i/o is entirely handled by the hardware's device drivers and the o/s has no further interaction other than at the file level then I am:

A. Disappointed
B. Just experiencing reality

- and the only option is to throw faster/better hardware at the problem.
Skillset: VMS,DOS,Windows Sysadmin from 1985, fault-tolerance, VaxCluster, Alpha,Sparc. DCL,QB,VBDOS- VB6,.NET, PHP,NODE.JS, Graphic Design, Project Manager, CMS, Quad Electronics. classic cars & m'bikes. Artist in water & oils. Historian.
User avatar
dizt3mp3r
Posts: 1874
Joined: Mon Jun 14, 2010 5:54 pm

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

Post by dizt3mp3r »

Not trying to open this thread to cause dischord, in fact really wanting to avoid it, I simply want to ask a question to those that have the knowledge for my own understanding.

I already have a reasonably good understanding of i/o under VMS as a VMS sys admin, knowing that NT was influenced by VMS and is's initial designer Dave Cutler I could assume that NT and ReactOS i/o scheduling system was designed in the same manner (I know I would be completely wrong). There are guides available on i/o scheduling for Linux, one exists on wikipedia here: https://en.wikipedia.org/wiki/I/O_scheduling. Is there a document used by the ReactOS team that describes how the ReactOS i/o scheduling is achieved? Does the ReactOS team use the MS documentation?
Skillset: VMS,DOS,Windows Sysadmin from 1985, fault-tolerance, VaxCluster, Alpha,Sparc. DCL,QB,VBDOS- VB6,.NET, PHP,NODE.JS, Graphic Design, Project Manager, CMS, Quad Electronics. classic cars & m'bikes. Artist in water & oils. Historian.
MadWolf
Posts: 688
Joined: Sat Dec 31, 2005 4:19 am
Contact:

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

Post by MadWolf »

hi
is this what you are looking for

Understanding the Windows I/O System
https://www.microsoftpressstore.com/art ... 9&seqNum=3

Overview of the Windows I/O Model
https://docs.microsoft.com/en-us/window ... -i-o-model

Windows I/O Priorities (NT6+)
https://bitsum.com/pl_io_priority.php
User avatar
dizt3mp3r
Posts: 1874
Joined: Mon Jun 14, 2010 5:54 pm

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

Post by dizt3mp3r »

Thankyou!
Skillset: VMS,DOS,Windows Sysadmin from 1985, fault-tolerance, VaxCluster, Alpha,Sparc. DCL,QB,VBDOS- VB6,.NET, PHP,NODE.JS, Graphic Design, Project Manager, CMS, Quad Electronics. classic cars & m'bikes. Artist in water & oils. Historian.
User avatar
Massimone
Posts: 2
Joined: Mon Dec 25, 2017 9:59 pm

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

Post by Massimone »

I know about nothing on the details of the windows I/O model or any other technicalities, but I can confirm most of what reported about system freezes and graphic tearings on Windows XP (any service pack) since I worked, and played, and programmed, and offered tech support on it for more than 10 years.

I'm resuming this old thread because I'd like to know whether ReactOS will show the same behaviour or if you guys have created a better-than-that I/O system, and THIS answer had not yet been given :lol:

CD I/O: in my experience it's absolutely normal for XP user interface to freeze for few seconds while accessing a new CD. If anything goes wrong (reread/retry/abort), the system stays in this frozen state for much longer, answering to clicks and keypress only from time to time. And yes, the XP interface itself begins to rot, showing blank zones and/or out-of-place graphics.

HD I/O: with heavy disk I/O load, XP works fine when all the load comes from a single program. When two or more program does intensive access to disk(s) at the same time, general system performance degrades quickly and the user interface becomes more and more unresponsive.

So: how is the ReactOS I/O system, compared to XP's? Better, worse, on par? Have you flattened those old bumps or not? ;)
Post Reply

Who is online

Users browsing this forum: No registered users and 37 guests