Design architecture

NTDEV
1

Hi all,
one of my customers needs to forward data stream incoming from a bluetooth device (Serial Port Profile) to a serial line with the lowest possible latency (< 25 mS).
Using an application which reads from bluetooth device and writes over the serail line is sometimes not fast enough :frowning:
I really know that Windows XP is NOT real-time, so at the moment I have just 2 ideas:
Option A)
Porting all the stuff to Windows CE which is real-time.
Not sure they will agree to this solution :frowning:
Option B)
Write a filter driver over BTMODEM
In filter receive callback queue a worker item
In the worker item callback invoke the serial driver write dispacth function

Any suggestion will be highly appreciated,
PaoloC

2

For clarit: That is 25 MILLIseconds, right?

Measuring from what to what?

25 milliseconds should be very achievableā€¦

Peter
OSR

3

Drivers are not faster than apps just because they are in kernel mode. How are you reading from the bth serial port? Asynchronous or sync? How many pending reads at a time? What is the priority of the app threadd reading and writing?

d

dent from a phpne with no keynoard

From: xxxxx@tin.it
Sent: November 05, 2010 9:04 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Design architecture

Hi all,
one of my customers needs to forward data stream incoming from a bluetooth device (Serial Port Profile) to a serial line with the lowest possible latency (< 25 mS).
Using an application which reads from bluetooth device and writes over the serail line is sometimes not fast enough :frowning:
I really know that Windows XP is NOT real-time, so at the moment I have just 2 ideas:
Option A)
Porting all the stuff to Windows CE which is real-time.
Not sure they will agree to this solution :frowning:
Option B)
Write a filter driver over BTMODEM
In filter receive callback queue a worker item
In the worker item callback invoke the serial driver write dispacth function

Any suggestion will be highly appreciated,
PaoloC

ā€” NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

4

Probably the biggest can of worms you can open in software is anything related to the words ā€œreal-timeā€. Take caution in your statement that Windows CE is ā€œreal-timeā€ (Iā€™m even regretting just writing this sentence knowing the backlash it could provoke). Iā€™d take a step back and look at the bigger picture. Have you already profiled that your deadline requirement is in the sub 25ms range? When designing any system you can sort of put everything in one of three categories - will a missed deadline cause 1) death, 2) monetary loss or 3) frustration and then you go from there. If youā€™re not asking these questions up front then itā€™s sort of the ā€œif you have to ask the price, you canā€™t afford itā€ corollary. Based on the one line of info you gave us about your app Iā€™d be very surprised if Windows XP/Vista/7 isnā€™t up to the job. If not, then you need to go down the fun path of looking at soft real-time OSes, hard real-time, rate-monotonic scheduling, etc, etc.

Again, Iā€™m willing to bet Windows is up to the challenge for your given needs. Iā€™d prototype it on ā€œdesktopā€ Windows first, profile it and go from there.

D.J.

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@tin.it
Sent: Friday, November 05, 2010 9:03 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Design architecture

Hi all,
one of my customers needs to forward data stream incoming from a bluetooth device (Serial Port Profile) to a serial line with the lowest possible latency (< 25 mS).
Using an application which reads from bluetooth device and writes over the serail line is sometimes not fast enough :frowning:
I really know that Windows XP is NOT real-time, so at the moment I have just 2 ideas:
Option A)
Porting all the stuff to Windows CE which is real-time.
Not sure they will agree to this solution :frowning:
Option B)
Write a filter driver over BTMODEM
In filter receive callback queue a worker item
In the worker item callback invoke the serial driver write dispacth function

Any suggestion will be highly appreciated,
PaoloC

ā€” NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

5

This is off-topic, BUT:

According to one of the WinCE architects I was talking to a couple of weeks ago, Windows CE is in fact a soft real-time system. There are definitely very stringent (MICROsecond-level) latency guarantees available to drivers (which is the area we were discussing).

Donā€™t trust MSFT? How about this from Dedicated Systems: http://download.microsoft.com/download/7/2/f/72fef3b0-9545-46a4-8886-a94f265df9c4/EVA-2.9-TST-CE-x86-01-Iss1.00.pdf

I can imagine your hesitancy, given that the statement implied an inaccurate conclusion.

Peter
OSR

6

I hear ya. This is exactly why I put in my disclaimer and why I still stand by it. And what I mean by that is in no way meant to be taken as a criticism of CE but rather to state that calling anything just ā€œreal-timeā€ is not a sufficient enough description and requires at the very least a prefix of ā€œhardā€ or ā€œsoftā€ but in reality an even more thorough description.

But I digress - Iā€™ve been a part of these types of discussions too many times over the past 12 years to know the ensuing stalemate is coming so Iā€™ll stop now.

And just for the record, I am indeed a proponent of CE. Iā€™m working on a particularly frustrating FreeRTOS project right now and would absolutely welcome in CE in for nothing else than the ease of development within it (and, yes, thatā€™s a complement).

Ok, I think Iā€™ve dug myself into a sufficiently sized hole now so Iā€™ll stopā€¦ :wink:

On Nov 5, 2010, at 9:57 AM, xxxxx@osr.com wrote:

This is off-topic, BUT:

According to one of the WinCE architects I was talking to a couple of weeks ago, Windows CE is in fact a soft real-time system. There are definitely very stringent (MICROsecond-level) latency guarantees available to drivers (which is the area we were discussing).

Donā€™t trust MSFT? How about this from Dedicated Systems: http://download.microsoft.com/download/7/2/f/72fef3b0-9545-46a4-8886-a94f265df9c4/EVA-2.9-TST-CE-x86-01-Iss1.00.pdf

I can imagine your hesitancy, given that the statement implied an inaccurate conclusion.

Peter
OSR

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

7

Thanks all for your answers.
I agree that WinCE is soft-real-time, anyway I like it !
I can configure the thread reading from BT and writing to COM with a
specific priority (higher than quite any other threads in the system).
Returning on XP (I presume my customer will not like the CE suggestion) I
was thinking to skip the thread scheduling latencies sending an IRP from BT
receive callback to COM write dispatch routine.
But I am not sure I can send an IRP to COM driver directly from BT receive
callback as COM dispatch may expect to be called from passive level.
Am I correct ?
At the moment I have no visibility of customer application; I will
investigate how many I/O are queued, synch/asynch etc. etc. next week.

Again thanks,
PaoloC

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of D.J. Stachniak
Sent: Friday, November 05, 2010 6:36 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Design architecture

I hear ya. This is exactly why I put in my disclaimer and why I still stand
by it. And what I mean by that is in no way meant to be taken as a
criticism of CE but rather to state that calling anything just ā€œreal-timeā€
is not a sufficient enough description and requires at the very least a
prefix of ā€œhardā€ or ā€œsoftā€ but in reality an even more thorough description.

But I digress - Iā€™ve been a part of these types of discussions too many
times over the past 12 years to know the ensuing stalemate is coming so Iā€™ll
stop now.

And just for the record, I am indeed a proponent of CE. Iā€™m working on a
particularly frustrating FreeRTOS project right now and would absolutely
welcome in CE in for nothing else than the ease of development within it
(and, yes, thatā€™s a complement).

Ok, I think Iā€™ve dug myself into a sufficiently sized hole now so Iā€™ll
stopā€¦ :wink:

On Nov 5, 2010, at 9:57 AM, xxxxx@osr.com wrote:

This is off-topic, BUT:

According to one of the WinCE architects I was talking to a couple of weeks
ago, Windows CE is in fact a soft real-time system. There are definitely
very stringent (MICROsecond-level) latency guarantees available to drivers
(which is the area we were discussing).

Donā€™t trust MSFT? How about this from Dedicated Systems:
http://download.microsoft.com/download/7/2/f/72fef3b0-9545-46a4-8886-a94f265
df9c4/EVA-2.9-TST-CE-x86-01-Iss1.00.pdf

I can imagine your hesitancy, given that the statement implied an inaccurate
conclusion.

Peter
OSR

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.864 / Virus Database: 271.1.1/3239 - Release Date: 11/05/10
08:34:00

8

Judicious use of elevated thread priorities usually help for those low-CPU small-latency applications. You donā€™t need to make it realtime priority.

Just remember that the thread should never in any circumstances fall to a tight loop.

9

For the most effective reply, you could try answering the questions I posed in my initial response:

Well, I donā€™t know anything about the BT stackā€¦ but the RULE is not to forward IRPs at IRQL DISPATCH_LEVEL unless you *know* the receiving driver is expecting it. Also, you need to be careful with stack space usage.

Even if you send the requests to a (driver-created) worker thread pool to be forwarded, with appropriate thread priorities (as Mr. Grig described, though you might want to TRY putting the worker thread into the lowest part of the real-time range as a test), the context switching overhead is likely to amount to whatā€¦ 1ms?? So, 25ms?? That should be easy.

Againā€¦ depending on what youā€™re measuringā€¦ 25ms from what to what?

Peter
OSR

10

I did not yet had a technical meeting with the customer, but for what I have
understood now,
25 milliseconds seems to be measured with an oscilloscope from device A to
device B crossing:
Bluetooth stack + an application + serial port stack.
I presume that latency is mostly generated within the application, but my
customer provides device B only.
I posted the question to suggest some alternative for data tunneling in case
they cannot modify the application.
Hope may have more info after technical meeting next week.
For now thanks a lot to everybody,
PaoloC

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Saturday, November 06, 2010 5:42 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Design architecture

For the most effective reply, you could try answering the questions I posed
in my initial response:

Well, I donā€™t know anything about the BT stackā€¦ but the RULE is not to
forward IRPs at IRQL DISPATCH_LEVEL unless you *know* the receiving driver
is expecting it. Also, you need to be careful with stack space usage.

Even if you send the requests to a (driver-created) worker thread pool to be
forwarded, with appropriate thread priorities (as Mr. Grig described, though
you might want to TRY putting the worker thread into the lowest part of the
real-time range as a test), the context switching overhead is likely to
amount to whatā€¦ 1ms?? So, 25ms?? That should be easy.

Againā€¦ depending on what youā€™re measuringā€¦ 25ms from what to what?

Peter
OSR

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.864 / Virus Database: 271.1.1/3239 - Release Date: 11/05/10
20:34:00

11

If they cannot modify the app, why is CE even an option? That means an entirely new appā€¦

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Paolo Cazzola
Sent: Saturday, November 06, 2010 4:34 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Design architecture

I did not yet had a technical meeting with the customer, but for what I have understood now,
25 milliseconds seems to be measured with an oscilloscope from device A to device B crossing:
Bluetooth stack + an application + serial port stack.
I presume that latency is mostly generated within the application, but my customer provides device B only.
I posted the question to suggest some alternative for data tunneling in case they cannot modify the application.
Hope may have more info after technical meeting next week.
For now thanks a lot to everybody,
PaoloC

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Saturday, November 06, 2010 5:42 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Design architecture

For the most effective reply, you could try answering the questions I posed in my initial response:

Well, I donā€™t know anything about the BT stackā€¦ but the RULE is not to forward IRPs at IRQL DISPATCH_LEVEL unless you *know* the receiving driver is expecting it. Also, you need to be careful with stack space usage.

Even if you send the requests to a (driver-created) worker thread pool to be forwarded, with appropriate thread priorities (as Mr. Grig described, though you might want to TRY putting the worker thread into the lowest part of the real-time range as a test), the context switching overhead is likely to amount to whatā€¦ 1ms?? So, 25ms?? That should be easy.

Againā€¦ depending on what youā€™re measuringā€¦ 25ms from what to what?

Peter
OSR

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.864 / Virus Database: 271.1.1/3239 - Release Date: 11/05/10
20:34:00

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer