Hello All
I did some sample tests on reading sectors from say 25000->30000.
When i went from 25000->30,000 sectors i got a total time of say t seconds.
But when i did the reading sectors from 30,000->25000 i got nearly a t*5
seconds.
I assume its setting of file pointers thats giving this huge difference.
Or is there any other reason due to which i am going wrong?
TIA
Shal
The sample code is
//test 1
timeclock();
for(int ni=0;ni<5000;ni++)
{
offset+=512;
ReadSector(offset,szSectVal);
}
timeclock();
//test 2
timeclock();
for(int ni=5000;ni>0;ni–)
{
offset-=512;
ReadSector(offset,szSectVal);
}
timeclock();
ReadSector(LONGLONG gOffset,unsigned char *pszSectorValue)
{
FILE_POSITION_INFORMATION oFilePos;
oFilePos.CurrentByteOffset.QuadPart=gOffset;
rc=ZwSetInformationFile(hReadWriteSectorHandle,&IoStatusReadWrite,&oFilePos,
sizeof(FILE_POSITION_INFORMATION),FilePositionInformation);
if(!NT_SUCCESS(rc))
return rc;
rc=ZwReadFile(hReadWriteSectorHandle,
NULL,
NULL,
NULL,
&IoStatusReadWrite,
pszSectorValue,
nBlockSize,
NULL,
NULL);
}
What kind of media? Reading in reverse order on CD/DVD is likely slower
than reading forward. Other possibilities include OS and/or device
optimizations for forward reading (i.e., read-ahead caching).
Chuck
----- Original Message -----
From: “Shalini”
Newsgroups: ntdev
To: “Windows System Software Devs Interest List”
Sent: Monday, August 09, 2004 9:42 PM
Subject: [ntdev] ZwReadFile Speed Problem.
> Hello All
> I did some sample tests on reading sectors from say 25000->30000.
> When i went from 25000->30,000 sectors i got a total time of say t
seconds.
> But when i did the reading sectors from 30,000->25000 i got nearly a
t*5
> seconds.
>
> I assume its setting of file pointers thats giving this huge
difference.
> Or is there any other reason due to which i am going wrong?
>
> TIA
> Shal
>
> The sample code is
>
> //test 1
> timeclock();
> for(int ni=0;ni<5000;ni++)
> {
> offset+=512;
> ReadSector(offset,szSectVal);
> }
> timeclock();
>
>
> //test 2
> timeclock();
> for(int ni=5000;ni>0;ni–)
> {
> offset-=512;
> ReadSector(offset,szSectVal);
> }
> timeclock();
>
>
> ReadSector(LONGLONG gOffset,unsigned char *pszSectorValue)
> {
> FILE_POSITION_INFORMATION oFilePos;
> oFilePos.CurrentByteOffset.QuadPart=gOffset;
>
>
rc=ZwSetInformationFile(hReadWriteSectorHandle,&IoStatusReadWrite,&oFile
Pos,
> sizeof(FILE_POSITION_INFORMATION),FilePositionInformation);
>
>
> if(!NT_SUCCESS(rc))
> return rc;
>
> rc=ZwReadFile(hReadWriteSectorHandle,
> NULL,
> NULL,
> NULL,
> &IoStatusReadWrite,
> pszSectorValue,
> nBlockSize,
> NULL,
> NULL);
>
> }
Hi,
Its Hard disk
Is there any way to solve it…???
What i thought was internally as the handle is global it might do a SEEK_CUR
and so it shud be the same
for both Forward as well as Backward reading.
Regards
Shal
“Chuck Batson” wrote in message
news:xxxxx@ntdev…
> What kind of media? Reading in reverse order on CD/DVD is likely slower
> than reading forward. Other possibilities include OS and/or device
> optimizations for forward reading (i.e., read-ahead caching).
>
> Chuck
>
> ----- Original Message -----
> From: “Shalini”
> Newsgroups: ntdev
> To: “Windows System Software Devs Interest List”
> Sent: Monday, August 09, 2004 9:42 PM
> Subject: [ntdev] ZwReadFile Speed Problem.
>
>
> > Hello All
> > I did some sample tests on reading sectors from say 25000->30000.
> > When i went from 25000->30,000 sectors i got a total time of say t
> seconds.
> > But when i did the reading sectors from 30,000->25000 i got nearly a
> t*5
> > seconds.
> >
> > I assume its setting of file pointers thats giving this huge
> difference.
> > Or is there any other reason due to which i am going wrong?
> >
> > TIA
> > Shal
> >
> > The sample code is
> >
> > //test 1
> > timeclock();
> > for(int ni=0;ni<5000;ni++)
> > {
> > offset+=512;
> > ReadSector(offset,szSectVal);
> > }
> > timeclock();
> >
> >
> > //test 2
> > timeclock();
> > for(int ni=5000;ni>0;ni–)
> > {
> > offset-=512;
> > ReadSector(offset,szSectVal);
> > }
> > timeclock();
> >
> >
> > ReadSector(LONGLONG gOffset,unsigned char *pszSectorValue)
> > {
> > FILE_POSITION_INFORMATION oFilePos;
> > oFilePos.CurrentByteOffset.QuadPart=gOffset;
> >
> >
> rc=ZwSetInformationFile(hReadWriteSectorHandle,&IoStatusReadWrite,&oFile
> Pos,
> > sizeof(FILE_POSITION_INFORMATION),FilePositionInformation);
> >
> >
> > if(!NT_SUCCESS(rc))
> > return rc;
> >
> > rc=ZwReadFile(hReadWriteSectorHandle,
> > NULL,
> > NULL,
> > NULL,
> > &IoStatusReadWrite,
> > pszSectorValue,
> > nBlockSize,
> > NULL,
> > NULL);
> >
> > }
>
>
[sarcasm on]
exchange the polarity of powersupply for your harddisk, then the disk
rotate in the other direction. 
[sarcasm off]
[speculate on]
If you know the cache-strategy of your particular drive it might be
possible to do intermediate reads (backwards) that are more than one sector away.
These intermediate reads help filling the read-ahead buffers, so that
the single sector back step is accelerated.
[speculate off]
what are you trying to achieve by this ?
Norbert.
"Nobody will ever win the battle of the sexes. There's too much
fraternizing with the enemy. - Henry Kissinger"
---- snip ----
Hi,
Its Hard disk
Is there any way to solve it...?????
What i thought was internally as the handle is global it might do a SEEK_CUR
and so it shud be the same
for both Forward as well as Backward reading.
Regards
Shal
"Chuck Batson" wrote in message
> news:xxxxx@ntdev...
>> What kind of media? Reading in reverse order on CD/DVD is likely slower
>> than reading forward. Other possibilities include OS and/or device
>> optimizations for forward reading (i.e., read-ahead caching).
>>
>> Chuck
>>
>> ----- Original Message -----
>> From: "Shalini"
>> Newsgroups: ntdev
>> To: "Windows System Software Devs Interest List"
>> Sent: Monday, August 09, 2004 9:42 PM
>> Subject: [ntdev] ZwReadFile Speed Problem.
>>
>>
>> > Hello All
>> > I did some sample tests on reading sectors from say 25000->30000.
>> > When i went from 25000->30,000 sectors i got a total time of say t
>> seconds.
>> > But when i did the reading sectors from 30,000->25000 i got nearly a
>> t*5
>> > seconds.
>> >
>> > I assume its setting of file pointers thats giving this huge
>> difference.
>> > Or is there any other reason due to which i am going wrong?
>> >
>> > TIA
>> > Shal
>> >
>> > The sample code is
>> >
>> > //test 1
>> > timeclock();
>> > for(int ni=0;ni<5000;ni++)
>> > {
>> > offset+=512;
>> > ReadSector(offset,szSectVal);
>> > }
>> > timeclock();
>> >
>> >
>> > //test 2
>> > timeclock();
>> > for(int ni=5000;ni>0;ni--)
>> > {
>> > offset-=512;
>> > ReadSector(offset,szSectVal);
>> > }
>> > timeclock();
>> >
>> >
>> > ReadSector(LONGLONG gOffset,unsigned char *pszSectorValue)
>> > {
>> > FILE_POSITION_INFORMATION oFilePos;
>> > oFilePos.CurrentByteOffset.QuadPart=gOffset;
>> >
>> >
>> rc=ZwSetInformationFile(hReadWriteSectorHandle,&IoStatusReadWrite,&oFile
>> Pos,
>> > sizeof(FILE_POSITION_INFORMATION),FilePositionInformation);
>> >
>> >
>> > if(!NT_SUCCESS(rc))
>> > return rc;
>> >
>> > rc=ZwReadFile(hReadWriteSectorHandle,
>> > NULL,
>> > NULL,
>> > NULL,
>> > &IoStatusReadWrite,
>> > pszSectorValue,
>> > nBlockSize,
>> > NULL,
>> > NULL);
>> >
>> > }
>>
>>
> ---
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
> You are currently subscribed to ntdev as: xxxxx@stollmann.de
> To unsubscribe send a blank email to xxxxx@lists.osr.com
---- snip ----
> Hello All
I did some sample tests on reading sectors from say 25000->30000.
When i went from 25000->30,000 sectors i got a total time of say t
seconds.
But when i did the reading sectors from 30,000->25000 i got nearly a t*5
seconds.
I assume its setting of file pointers thats giving this huge difference.
Or is there any other reason due to which i am going wrong?
Well, if I’m not totally mistaken every modern disk has a cache, and maybe
some (or all) disks (pre-)cache not the whole track when reading a sector
but
only the sectors after the one requested. Makes perfect sense for most
applications because it doesn’t waste cache-memory on something that’s
probably never requested.
What may help is to not wait for the 1st IO to complete before queuing the
others. So you just queue - say 100 or 1000 requests, and then wait for
them
to complete. At least in usermode (with FILE_FLAG_NO_BUFFERING and
FILE_FLAG_OVERLAPPED set) queuing 1000 random requests is ~3-5 times
faster
then doint it one at a time - windows seems to sort the requests based on
the LBA or someting like that.
If you know beforehand what 100 or 1000 sectors you will need you may also
just quicksort() them based on the file-offset - should do fine for little
fragmented files and every kind of disk I can imagine.
(ok, to be exact introsort might be the better choice than quicksort() 
Of course if you’re reading a real file-system-file here, maybe there’s
some issue with the file-system (NTFS, FAT?) storing/caching only the
LBAs for following sectors and not preceding. I don’t know how NTFS does,
but maybe there’s also the LBA of the next sector stored in each
data-sector.
Amiga-OS did it that way to minimize seek-operations when reading files
(caching all LBAs of a file when opening was surely out-of-the-question
those days with only 512kB of memory…).
Regards,
Paul Groke
On Mon, 2004-08-09 at 15:42, xxxxx@tab.at wrote:
If you know beforehand what 100 or 1000 sectors you will need you may also
just quicksort() them based on the file-offset
In general, don’t use recursive sorts in the kernel.
-sd
Hi Don!
> If you know beforehand what 100 or 1000 sectors you will need you may
also
> just quicksort() them based on the file-offset
In general, don’t use recursive sorts in the kernel.
Good point. But is there a problem if the maximum size is known and small
enough and one limits the recursion-depth? (the usual “recurse the smaller
partition, iterate the bigger” quicksort implementation goes no more then
log2(N) calls deep)
Surely I get the point, but I think that’s just like the “don’t use C++
in the kernel” thing - one just needs to know what one’s doning.
For 1000 elements an “intelligent” quicksort would go 10 calls deep max.
- which imho would not really be a big problem.
Or am I missing something?
But you’re right, I should have thought of that and should have
mentioned it 
Btw: is there a way to query how much stack-space is “left” e.g. when
called from another driver via internal device-control - or even for
testing/debugging rather complicated drivers with a lot of internal
callbacks? Probably even a simple way to setup a new stack if one needs
more stackspace?
Regards,
Paul Groke
On Mon, 2004-08-09 at 17:02, xxxxx@tab.at wrote:
Hi Don!
That was me (Steve), actually; don’t blame Don for my rants.
> > If you know beforehand what 100 or 1000 sectors you will need you may
also
> > just quicksort() them based on the file-offset
>
> In general, don’t use recursive sorts in the kernel.
Good point. But is there a problem if the maximum size is known and small
enough and one limits the recursion-depth? (the usual “recurse the smaller
partition, iterate the bigger” quicksort implementation goes no more then
log2(N) calls deep)
It’s still better to flatten your sort out into a for loop or
something. You leave yourself open to security problems if someone
feeds you a big buffer to sort - it’s a DoS at least.
Surely I get the point, but I think that’s just like the “don’t use C++
in the kernel” thing - one just needs to know what one’s doning.
For 1000 elements an “intelligent” quicksort would go 10 calls deep max.
- which imho would not really be a big problem.
Or am I missing something?
Depends on where you are in the call stack and how much stack you
allocate in each frame. Remember, the kernel has a fixed 12KB stack. I
guess you could do something goofy with IoGetRemainingStackSize(), but
it’d be better to just use a flat sort IMO.
Btw: is there a way to query how much stack-space is “left” e.g. when
called from another driver via internal device-control - or even for
testing/debugging rather complicated drivers with a lot of internal
callbacks? Probably even a simple way to setup a new stack if one needs
more stackspace?
Funny you should ask. see above, and also look at
IoGetStackLimits().
-sd
Hi Steve & Don,
I’m sorry I messed up 2 messages and thought it was Don
who answered the ZwReadFile thread…
(I hate lotus-notes for not being able to quote like
“normal” email-clients do, and doing it “by hand” such
things can happen… )
Regards,
Paul Groke