Hi All,
MSDN documentation states that method_buffered should be used for
application interaction only if the amount of data being transferred is not
too large.
Is there any recommended upper limit of datasize that can be transferred
using this method ?
Thanks,
Samarth
Around PAGE_SIZE.
----- Original Message -----
From: “Samarth Sharma”
Newsgroups: ntdev
To: “NT Developers Interest List”
Sent: Friday, July 11, 2003 11:55 AM
Subject: [ntdev] METHOD_BUFFERED
> Hi All,
>
> MSDN documentation states that method_buffered should be used for
> application interaction only if the amount of data being transferred
is not
> too large.
> Is there any recommended upper limit of datasize that can be
transferred
> using this method ?
>
> Thanks,
> Samarth
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to
xxxxx@lists.osr.com
Hi Samarth,
i’ve been transferring 10 mb of data with method_buffered
in each iteration of a loop (in my virtual wannabe usermode
disk) without really needing it;
first i thought size wouldnt matter at all then i considered
100% cpu in the task manager; when i reduced the size
to transport only whats necessary (yes i know it should be
that way anyway) it was like max. 5% cpu.
i conclude that size doesnt matter but is pretty pretty slow
when it gets too large.
ciao
Hannes
Not exactly. It depends on data size and how often you are using it. For
example you want to transfer 8K data once in the life time of the
application or boot. I would go with METHOD_BUFFERED.
At the same time if I want to transfer 4K of data every second I
will go with METHOD_IN_DIRECT/METHOD_OUT_DIRECT/METHOD_NEITHER
-Srin.
-----Original Message-----
From: Samarth Sharma [mailto:xxxxx@mynetsec.com]
Sent: Friday, July 11, 2003 12:56 AM
To: NT Developers Interest List
Subject: [ntdev] METHOD_BUFFEREDHi All,
MSDN documentation states that method_buffered should be used for
application interaction only if the amount of data being transferred
is
not
too large.
Is there any recommended upper limit of datasize that can be
transferred
using this method ?Thanks,
Samarth
You are currently subscribed to ntdev as: xxxxx@nai.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
It’s going to be a while before a fast P4 runs out of cycles, but if that’s
what hurts, you can try to recode the data movement to use the P4’s SIMD
functionality. Intel has distributed a couple of very fast data movement
routines that take advantage of the 128-bit instructions and of the cache
management instructions, you can start there.
Alberto.
-----Original Message-----
From: xxxxx@NAI.com [mailto:xxxxx@NAI.com]
Sent: Friday, July 11, 2003 11:51 AM
To: NT Developers Interest List
Subject: [ntdev] RE: METHOD_BUFFERED
Not exactly. It depends on data size and how often you are using it. For
example you want to transfer 8K data once in the life time of the
application or boot. I would go with METHOD_BUFFERED.
At the same time if I want to transfer 4K of data every second I
will go with METHOD_IN_DIRECT/METHOD_OUT_DIRECT/METHOD_NEITHER
-Srin.
-----Original Message-----
From: Samarth Sharma [mailto:xxxxx@mynetsec.com]
Sent: Friday, July 11, 2003 12:56 AM
To: NT Developers Interest List
Subject: [ntdev] METHOD_BUFFEREDHi All,
MSDN documentation states that method_buffered should be used for
application interaction only if the amount of data being transferred
is
not
too large.
Is there any recommended upper limit of datasize that can be
transferred
using this method ?Thanks,
Samarth
You are currently subscribed to ntdev as: xxxxx@nai.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.
Why? What if the setup cost for building an MDL is greater than the cost of
copying 4K of data? Then it really doesn’t matter at all what the frequency
is, does it? METHOD_NEITHER is generally inappropriate for anything other
than top-level drivers.
=====================
Mark Roddy
Hollis Technology Solutions
www.hollistech.com
xxxxx@hollistech.com
-----Original Message-----
From: xxxxx@NAI.com [mailto:xxxxx@NAI.com]
Sent: Friday, July 11, 2003 11:51 AM
To: NT Developers Interest List
Subject: [ntdev] RE: METHOD_BUFFERED
Not exactly. It depends on data size and how often you are using it. For
example you want to transfer 8K data once in the life time of the
application or boot. I would go with METHOD_BUFFERED.
At the same time if I want to transfer 4K of data every second I
will go with METHOD_IN_DIRECT/METHOD_OUT_DIRECT/METHOD_NEITHER
-Srin.
-----Original Message-----
From: Samarth Sharma [mailto:xxxxx@mynetsec.com]
Sent: Friday, July 11, 2003 12:56 AM
To: NT Developers Interest List
Subject: [ntdev] METHOD_BUFFEREDHi All,
MSDN documentation states that method_buffered should be used for
application interaction only if the amount of data being transferred
is
not
too large.
Is there any recommended upper limit of datasize that can be
transferred
using this method ?Thanks,
Samarth
You are currently subscribed to ntdev as: xxxxx@nai.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
You are currently subscribed to ntdev as: xxxxx@stratus.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
Thank you. The information was very helpful. I certainly got more than i had
hoped for.
Thanks again,
Samarth
“Samarth Sharma” wrote in message news:xxxxx@ntdev…
>
> I certainly got more than i had hoped for.
>
That’s often the case on this list. Occasionally, it’s even a good thing
Peter
Yes you are right. It is a good thing.
“Peter Viscarola” wrote in message news:xxxxx@ntdev…
>
>
> “Samarth Sharma” wrote in message
news:xxxxx@ntdev…
> >
> > I certainly got more than i had hoped for.
> >
>
> That’s often the case on this list. Occasionally, it’s even a good thing
>
>
> Peter
>
>
>
>