Sent: 01/24/2006
From: augustus_meyer
Message:I suspect a problem with high CPU-load (because of running VPC) AND high
interrupt load. So I would try to use one of the smart add-on cards for
additional serial ports to be installed on the host, which have their own
processor and buffer-HW.
Have a look at www.moxa.com, for instance.
"Norman Diamond" wrote:
Show quoted text
> An application is being tested in a Windows XP Embedded SP2 guest machine
> under Virtual PC 2004 SP1 on a Windows XP Pro SP2 real machine. Virtual PC
> settings give the guest machine's COM1 control of the real machine's COM1.
> The application calls SetupComm with both buffer sizes set to 1200. In
> these tests the external device sends 1036 bytes at a time. Baud rate
> 57600, 8-bit byte plus parity, so each of these transmissions takes about
> 200 milliseconds. DTR is permanently enabled because the device requires
> it. But the device is not capable of flow control (if we disable DTR then
> we lose data instead of delaying it, and the idea of software flow control
> is far beyond the capabilities of the device).
>
> As background, on some real machines running Windows XP Pro SP2, the
> application is getting CE_OVERRUN. We're trying to figure out what to do
> about that. But at least we know where it's happening. (Some of our
> experiments try a USB-serial adapter with a hardware receive buffer that's
> either 384 bytes or 4K bytes, we're not sure which, but we're still getting
> CE_OVERRUN.) Anyway, we've never seen CE_RXOVER with this application on a
> real machine.
>
> Under Virtual PC the application sometimes gets CE_RXOVER instead of
> CE_OVERRUN. Where can this be happening? Does Virtual PC set a buffer size
> that's smaller but just happens to be good enough 99% of the time, and then
> somehow reflect its own error into the guest machine's serial status? But
> doesn't the guest machine think the serial port is a real one (and maybe
> isn't it really the real one), so how could it be getting hit with a
> software error that isn't occuring in the guest machine?
>
> In this setup, where can CE_RXOVER possibly be coming from?
>
>
Sent: 01/30/2006
From: "Norman Diamond" <(email address - cut out)am>
Message:Thank you for your suggestions. Obviously the high interrupt load is a
problem, because it's also a problem on a real machine without VPC. The
thing I can't figure out is how the error becomes CE_RXOVER under VPC. I
cannot imagine how the driver's buffer, 1200 bytes long after a call to
SetupComm, can overflow in our situation.
On a real machine the error is CE_OVERRUN because the UART's buffer
overflows. That obviously avoids overflowing the driver's 1200 byte buffer.
(Of course there's no benefit from that because losing data at an earlier
stage still loses data.) I can't figure out how CE_RXOVER occurs in the
first place, and also can't figure out why it only happens under VPC.
CE_OVERRUN would be immediately understandable.
Some USB-serial adapters have long enough internal buffers that I think we
have decided to recommend them on real machines. I don't think the customer
will run this program under VPC, but still I posted because I can't figure
it out.
"augustus_meyer" <(email address - cut out)> wrote in message
news:(email address - cut out)...
Show quoted text
>I suspect a problem with high CPU-load (because of running VPC) AND high
> interrupt load. So I would try to use one of the smart add-on cards for
> additional serial ports to be installed on the host, which have their own
> processor and buffer-HW.
> Have a look at www.moxa.com, for instance.
>
> "Norman Diamond" wrote:
>
>> An application is being tested in a Windows XP Embedded SP2 guest machine
>> under Virtual PC 2004 SP1 on a Windows XP Pro SP2 real machine. Virtual
>> PC
>> settings give the guest machine's COM1 control of the real machine's
>> COM1.
>> The application calls SetupComm with both buffer sizes set to 1200. In
>> these tests the external device sends 1036 bytes at a time. Baud rate
>> 57600, 8-bit byte plus parity, so each of these transmissions takes about
>> 200 milliseconds. DTR is permanently enabled because the device requires
>> it. But the device is not capable of flow control (if we disable DTR
>> then
>> we lose data instead of delaying it, and the idea of software flow
>> control
>> is far beyond the capabilities of the device).
>>
>> As background, on some real machines running Windows XP Pro SP2, the
>> application is getting CE_OVERRUN. We're trying to figure out what to do
>> about that. But at least we know where it's happening. (Some of our
>> experiments try a USB-serial adapter with a hardware receive buffer
>> that's
>> either 384 bytes or 4K bytes, we're not sure which, but we're still
>> getting
>> CE_OVERRUN.) Anyway, we've never seen CE_RXOVER with this application on
>> a
>> real machine.
>>
>> Under Virtual PC the application sometimes gets CE_RXOVER instead of
>> CE_OVERRUN. Where can this be happening? Does Virtual PC set a buffer
>> size
>> that's smaller but just happens to be good enough 99% of the time, and
>> then
>> somehow reflect its own error into the guest machine's serial status?
>> But
>> doesn't the guest machine think the serial port is a real one (and maybe
>> isn't it really the real one), so how could it be getting hit with a
>> software error that isn't occuring in the guest machine?
>>
>> In this setup, where can CE_RXOVER possibly be coming from?
>>
>>
Sent: 02/15/2006
From: StanIAm
Message:I'm having a similar problem, but with TX buffer overflows occuring.
I have a program that is running in DOS (VPC) and sends/receives data at
115,200 baud. It's able to receive data all day, but when it tries to send
data it reports an overflow in the output buffer.
I'm not very sure how to trouble shoot this, but I'm pretty sure that an
overflow condition isn't occuring in "real life".
Data goes from the program (VPC DOS), through the virtual serial port (VPC),
into a named pipe (VPC), into a server application (real pc).
The server application has a 50 KB buffer and the named pipe has a 1 KB
buffer. Less than 1 KB of data is being sent in the test... it should not be
possible to hit an overflow, but somehow it's happening.
I'm extremely confused on this one and have no idea what to do.
Sent: 04/06/2009
From: "NagDymNvege"<(email address - cut out)>
Message:
http://frieo.eu.interia.pl/cantrdskes.html touching nurse stories
Posted via http://www.VirtualServerFaq.com - Brought to you by Business Information Technology Shop - http://www.bitshop.com
Show quoted text
> An application is being tested in a Windows XP Embedded SP2 guest machine
> under Virtual PC 2004 SP1 on a Windows XP Pro SP2 real machine. Virtual PC
> settings give the guest machine's COM1 control of the real machine's COM1.
> The application calls SetupComm with both buffer sizes set to 1200. In
> these tests the external device sends 1036 bytes at a time. Baud rate
> 57600, 8-bit byte plus parity, so each of these transmissions takes about
> 200 milliseconds. DTR is permanently enabled because the device requires
> it. But the device is not capable of flow control (if we disable DTR then
> we lose data instead of delaying it, and the idea of software flow control
> is far beyond the capabilities of the device).
>
> As background, on some real machines running Windows XP Pro SP2, the
> application is getting CE_OVERRUN. We're trying to figure out what to do
> about that. But at least we know where it's happening. (Some of our
> experiments try a USB-serial adapter with a hardware receive buffer that's
> either 384 bytes or 4K bytes, we're not sure which, but we're still getting
> CE_OVERRUN.) Anyway, we've never seen CE_RXOVER with this application on a
> real machine.
>
> Under Virtual PC the application sometimes gets CE_RXOVER instead of
> CE_OVERRUN. Where can this be happening? Does Virtual PC set a buffer size
> that's smaller but just happens to be good enough 99% of the time, and then
> somehow reflect its own error into the guest machine's serial status? But
> doesn't the guest machine think the serial port is a real one (and maybe
> isn't it really the real one), so how could it be getting hit with a
> software error that isn't occuring in the guest machine?
>
> In this setup, where can CE_RXOVER possibly be coming from?
Sent: 04/07/2009
From: "sweebuife"<(email address - cut out)>
Message:
http://mja-cars.rap4os.co.cc/map.html dollar rent a car 83814
Posted via http://www.VirtualServerFaq.com - Brought to you by Business Information Technology Shop - http://www.bitshop.com
Show quoted text
> An application is being tested in a Windows XP Embedded SP2 guest machine
> under Virtual PC 2004 SP1 on a Windows XP Pro SP2 real machine. Virtual PC
> settings give the guest machine's COM1 control of the real machine's COM1.
> The application calls SetupComm with both buffer sizes set to 1200. In
> these tests the external device sends 1036 bytes at a time. Baud rate
> 57600, 8-bit byte plus parity, so each of these transmissions takes about
> 200 milliseconds. DTR is permanently enabled because the device requires
> it. But the device is not capable of flow control (if we disable DTR then
> we lose data instead of delaying it, and the idea of software flow control
> is far beyond the capabilities of the device).
>
> As background, on some real machines running Windows XP Pro SP2, the
> application is getting CE_OVERRUN. We're trying to figure out what to do
> about that. But at least we know where it's happening. (Some of our
> experiments try a USB-serial adapter with a hardware receive buffer that's
> either 384 bytes or 4K bytes, we're not sure which, but we're still getting
> CE_OVERRUN.) Anyway, we've never seen CE_RXOVER with this application on a
> real machine.
>
> Under Virtual PC the application sometimes gets CE_RXOVER instead of
> CE_OVERRUN. Where can this be happening? Does Virtual PC set a buffer size
> that's smaller but just happens to be good enough 99% of the time, and then
> somehow reflect its own error into the guest machine's serial status? But
> doesn't the guest machine think the serial port is a real one (and maybe
> isn't it really the real one), so how could it be getting hit with a
> software error that isn't occuring in the guest machine?
>
> In this setup, where can CE_RXOVER possibly be coming from?
Sent: 04/07/2009
From: "BafUnioniacon"<(email address - cut out)>
Message:
http://khfuq.eu.interia.pl/yte.html online questionnaires to find the right career
Posted via http://www.VirtualServerFaq.com - Brought to you by Business Information Technology Shop - http://www.bitshop.com
Show quoted text
> An application is being tested in a Windows XP Embedded SP2 guest machine
> under Virtual PC 2004 SP1 on a Windows XP Pro SP2 real machine. Virtual PC
> settings give the guest machine's COM1 control of the real machine's COM1.
> The application calls SetupComm with both buffer sizes set to 1200. In
> these tests the external device sends 1036 bytes at a time. Baud rate
> 57600, 8-bit byte plus parity, so each of these transmissions takes about
> 200 milliseconds. DTR is permanently enabled because the device requires
> it. But the device is not capable of flow control (if we disable DTR then
> we lose data instead of delaying it, and the idea of software flow control
> is far beyond the capabilities of the device).
>
> As background, on some real machines running Windows XP Pro SP2, the
> application is getting CE_OVERRUN. We're trying to figure out what to do
> about that. But at least we know where it's happening. (Some of our
> experiments try a USB-serial adapter with a hardware receive buffer that's
> either 384 bytes or 4K bytes, we're not sure which, but we're still getting
> CE_OVERRUN.) Anyway, we've never seen CE_RXOVER with this application on a
> real machine.
>
> Under Virtual PC the application sometimes gets CE_RXOVER instead of
> CE_OVERRUN. Where can this be happening? Does Virtual PC set a buffer size
> that's smaller but just happens to be good enough 99% of the time, and then
> somehow reflect its own error into the guest machine's serial status? But
> doesn't the guest machine think the serial port is a real one (and maybe
> isn't it really the real one), so how could it be getting hit with a
> software error that isn't occuring in the guest machine?
>
> In this setup, where can CE_RXOVER possibly be coming from?
Sent: 04/23/2009
From: "googlaaa"<(email address - cut out)>
Message:
3ZEfAW http://google.com
Posted via http://www.VirtualServerFaq.com - Brought to you by Business Information Technology Shop - http://www.bitshop.com
Show quoted text
> An application is being tested in a Windows XP Embedded SP2 guest machine
> under Virtual PC 2004 SP1 on a Windows XP Pro SP2 real machine. Virtual PC
> settings give the guest machine's COM1 control of the real machine's COM1.
> The application calls SetupComm with both buffer sizes set to 1200. In
> these tests the external device sends 1036 bytes at a time. Baud rate
> 57600, 8-bit byte plus parity, so each of these transmissions takes about
> 200 milliseconds. DTR is permanently enabled because the device requires
> it. But the device is not capable of flow control (if we disable DTR then
> we lose data instead of delaying it, and the idea of software flow control
> is far beyond the capabilities of the device).
>
> As background, on some real machines running Windows XP Pro SP2, the
> application is getting CE_OVERRUN. We're trying to figure out what to do
> about that. But at least we know where it's happening. (Some of our
> experiments try a USB-serial adapter with a hardware receive buffer that's
> either 384 bytes or 4K bytes, we're not sure which, but we're still getting
> CE_OVERRUN.) Anyway, we've never seen CE_RXOVER with this application on a
> real machine.
>
> Under Virtual PC the application sometimes gets CE_RXOVER instead of
> CE_OVERRUN. Where can this be happening? Does Virtual PC set a buffer size
> that's smaller but just happens to be good enough 99% of the time, and then
> somehow reflect its own error into the guest machine's serial status? But
> doesn't the guest machine think the serial port is a real one (and maybe
> isn't it really the real one), so how could it be getting hit with a
> software error that isn't occuring in the guest machine?
>
> In this setup, where can CE_RXOVER possibly be coming from?
Sent: 04/23/2009
From: "googlaaa"<(email address - cut out)>
Message:
3ZEfAW http://google.com
Posted via http://www.VirtualServerFaq.com - Brought to you by Business Information Technology Shop - http://www.bitshop.com
Show quoted text
> An application is being tested in a Windows XP Embedded SP2 guest machine
> under Virtual PC 2004 SP1 on a Windows XP Pro SP2 real machine. Virtual PC
> settings give the guest machine's COM1 control of the real machine's COM1.
> The application calls SetupComm with both buffer sizes set to 1200. In
> these tests the external device sends 1036 bytes at a time. Baud rate
> 57600, 8-bit byte plus parity, so each of these transmissions takes about
> 200 milliseconds. DTR is permanently enabled because the device requires
> it. But the device is not capable of flow control (if we disable DTR then
> we lose data instead of delaying it, and the idea of software flow control
> is far beyond the capabilities of the device).
>
> As background, on some real machines running Windows XP Pro SP2, the
> application is getting CE_OVERRUN. We're trying to figure out what to do
> about that. But at least we know where it's happening. (Some of our
> experiments try a USB-serial adapter with a hardware receive buffer that's
> either 384 bytes or 4K bytes, we're not sure which, but we're still getting
> CE_OVERRUN.) Anyway, we've never seen CE_RXOVER with this application on a
> real machine.
>
> Under Virtual PC the application sometimes gets CE_RXOVER instead of
> CE_OVERRUN. Where can this be happening? Does Virtual PC set a buffer size
> that's smaller but just happens to be good enough 99% of the time, and then
> somehow reflect its own error into the guest machine's serial status? But
> doesn't the guest machine think the serial port is a real one (and maybe
> isn't it really the real one), so how could it be getting hit with a
> software error that isn't occuring in the guest machine?
>
> In this setup, where can CE_RXOVER possibly be coming from?
Wiki