Database Software on Wireless Network

Hi,

Has anybody had any experience with database software on wireless networks.
I have a customer who is saying that our application drops out 3 - 4 times a
day. We use Sybase 7.0 which is a stable, robust database technology which
runs on TCPIP. We have over 2500 pcs in our user base using wired networks
who are having no networking problems (we would be out of business if our
application was having problems with general networking).

All customers who have tried wireless to date have stopped using it due to
various reasons. This particular customer is adamant that it is our
application and can't even accept that is MAY be the network. In ODBC I have
adjusted the "timeout" period in seconds from 5 seconds to 30 seconds which
means that our app will not throw up a message until that time has expired.
I did this about a week ago and he is now saying that the app now freezes
and still drops out as well. The freezing to me is consistent with the
timeout period being increased.

The wireless encryption is not enabled as our app drops out heaps more. The
site has concrete walls and it is a Dental surgery so I can see the
potential for interference. The router is a Belkin and I am unsure of the
standard. It is not recent, is he ha had is for about 1 year.

Can anybody help with the following:
1. General advise on this topic.
2. Any website or other info.
3. Links to info on how to optimize software so that is more compatible with
wireless.

Thanks, any help much appreciated.

Regards
David

On Thu, 22 Jul 2004 22:31:06 +1000, "David Holstein"
<(E-Mail Removed)> wrote:

>Has anybody had any experience with database software on wireless networks.

Oh yes. I have a customer running point-o-sale software over a
wireless bridge (pair of DLink DWL-900AP+v1 radios). The software is
based on some ancient DBM whos name escapes me for the moment. The
application is called "MOMS". It runs perfectly well in the office on
their 100mbit/sec switched network. It runs not so well over the
wireless link.

What was happening was that I was getting clobbered by reflections
from vehicles along the wireless path. The DBM was not designed to
tolerate lost packets, had no integrity checks, and did not recover
from errors rather gracefully. Disconnects, crashes, hangs, lurches,
garbage data, and an irate customer were the initial problems.

After some wasted discussions with the software vendor (3rd generation
corporate buyout with outsourced everything), I could see that they
weren't going to do anything. It was therefore my job to improve
reliability up to the same level as the wired network.

The first thing I did was institute some level of monitoring. SNMP
and MRTG gave me a graph of the error rate over time. It was apparent
that it was a continuous situation which only went away at night (when
traffic was low). I decided to pipe the background music over the
link using 128Kbits/sec streaming audio. I set the buffering to about
1 second. Any interruption or packet loss would be instantly audible.
Clerks were told to avoid entering transactions if the music was
erratic. That worked but added complaints about the "crummy radio
station" to my things to do list.

The rest was an exercise in hardware selection, firmware upgrades, and
external antennas. I started with a pair of WAP11v1 radios. They
were garbage and produced continuous packet. They would also hang. I
switched to a pair of DWL-900AP+v1 radios and the continuous packet
loss was replaced with intermittent packet loss and no hangs. A
firmware upgrade improved the packet loss somewhat. Playing with the
wireless setting also made a difference. However, the real
improvement was using rediculously high gain antennas (12dBi patch)
for a distance of about 300ft and doing everything possible to get a
clear line of sight. The result was a dramatic improvement because of
reduced vehicle reflections and improved fade margin. It's been
running for about 2 years with minimal suprises (i.e. nearby leaky
microwave oven).

I realize that this didn't really answer your question. I don't know
what can be done to your DBM based application to improve reliability
in the face of packet loss. Offhand, I would think using transaction
files to allow for rollback in case of a trashout, along with using a
two phase commit method to insure integrity will be a help. However,
if the DBM disconnects, handgs, or deadlocks waiting for input,
neither of these will help. Dunno.


--
Jeff Liebermann (E-Mail Removed)
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 AE6KS 831-336-2558

If I understand correctly your application consists of a server database
with a 'thick' client that makes ODBC connections to it.

My advice would be to get a wireless setup in your lab yourself and use that
for testing

A simple test could be to see how your app handles an ethernet cable being
unplugged, but that's not the same as the WLAN connection behavior

A more robust solution would be to redesign your application to be less
dependent on long-lived connections, but that's probably a lot of effort.
Maybe tweaking of TCP settings could alleviate the problem a bit

Also, I found several sources on the Internet stating that using OLEDB
directly instead of ODBC could improve robustness and performance


"David Holstein" <(E-Mail Removed)> wrote in message
news:40ffb4e2$0$27221$(E-Mail Removed) om.au...
> Hi,
>
> Has anybody had any experience with database software on wireless
> networks.
> I have a customer who is saying that our application drops out 3 - 4 times
> a
> day. We use Sybase 7.0 which is a stable, robust database technology which
> runs on TCPIP. We have over 2500 pcs in our user base using wired networks
> who are having no networking problems (we would be out of business if our
> application was having problems with general networking).
>
> All customers who have tried wireless to date have stopped using it due to
> various reasons. This particular customer is adamant that it is our
> application and can't even accept that is MAY be the network. In ODBC I
> have
> adjusted the "timeout" period in seconds from 5 seconds to 30 seconds
> which
> means that our app will not throw up a message until that time has
> expired.
> I did this about a week ago and he is now saying that the app now freezes
> and still drops out as well. The freezing to me is consistent with the
> timeout period being increased.
>
> The wireless encryption is not enabled as our app drops out heaps more.
> The
> site has concrete walls and it is a Dental surgery so I can see the
> potential for interference. The router is a Belkin and I am unsure of the
> standard. It is not recent, is he ha had is for about 1 year.
>
> Can anybody help with the following:
> 1. General advise on this topic.
> 2. Any website or other info.
> 3. Links to info on how to optimize software so that is more compatible
> with
> wireless.
>
> Thanks, any help much appreciated.
>
> Regards
> David
>
>

"David Holstein" <(E-Mail Removed)> wrote in message news:<40ffb4e2$0$27221$(E-Mail Removed). com.au>...
> Hi,
>
> Has anybody had any experience with database software on wireless networks.
[CHOMP]
> Can anybody help with the following:
> 1. General advise on this topic.
> 2. Any website or other info.
> 3. Links to info on how to optimize software so that is more compatible with
> wireless.

I'd be quite interested in 2 and 3, myself; the problems I've seen running
database-backed applications over 802.11b have all been latency-related.
In other words, the bandwidth available is never saturated (I've seen 200Kb/s
without complaints in throughput, while there have been problems where the
actual throughput was peaking under 30Kb/s), but sometimes data takse too
long to get from point A to point B. With a Micros 3700 POS system, we didn't
have any trouble over a 22 Mbps (theoretical) connection for one of the kitchen
terminals in one location, yet when we relocated it to another on-site kitchen,
performance was intermittantly abysmal or nonexistant, while sometimes also
being quite decent. The distance the signal had to travel was about the same
in both cases, as was the hardware involved; the only differences were
interference (different devices nearby) and walls (different building, God only
knows what construction differences). Since I ran Cat5 to the new location,
the terminal has worked quite well.

Another application we have would do file-based inter-program
communication (i.e. product A writes a request, via SMB/CIFS, to
a specified directory on server B, which is running product B;
product B then reads, renames, and acts on that request file);
the request file would apparently get written but the client making
the request didn't think it worked due to the network latency,
at which point it would (apparently) check existence, note that the
file was not present on the server, and re-write it. The problem, of
course, was that the server was already acting on it and would then
treat the second request file as a new request, acting on it as well.
This we observed both as a significant problem on a 11Mbps point-
to-point wireless link and as an even more significant problem via
a VPN connection; the workaround was to change the way the client
application wrote the request file, shelling out of VB and asking
xcopy to move the file rather than opening the request file as a file
object directly.

As I said, I'd be very interested in more resources on the subject;
the troubleshooting we did with the file-latency issue seems to
suggest that it's actually a relatively low-level Windows Networking
(both the server and the client were Windows boxen) issue with
high-latency links if the newly-written file is quickly deleted or
moved by another process accessing the server.

Yes, what you are saying is right. It is a 'thick' client using ODBC. I will
look at test scenario and also OLEDB.


Regards
David

"Jeroen van Bemmel" <(E-Mail Removed)> wrote in message
news:d29a7$41000243$513bab05$(E-Mail Removed) ...
> If I understand correctly your application consists of a server database
> with a 'thick' client that makes ODBC connections to it.
>
> My advice would be to get a wireless setup in your lab yourself and use
that
> for testing
>
> A simple test could be to see how your app handles an ethernet cable being
> unplugged, but that's not the same as the WLAN connection behavior
>
> A more robust solution would be to redesign your application to be less
> dependent on long-lived connections, but that's probably a lot of effort.
> Maybe tweaking of TCP settings could alleviate the problem a bit
>
> Also, I found several sources on the Internet stating that using OLEDB
> directly instead of ODBC could improve robustness and performance
>
>
> "David Holstein" <(E-Mail Removed)> wrote in message
> news:40ffb4e2$0$27221$(E-Mail Removed) om.au...
> > Hi,
> >
> > Has anybody had any experience with database software on wireless
> > networks.
> > I have a customer who is saying that our application drops out 3 - 4
times
> > a
> > day. We use Sybase 7.0 which is a stable, robust database technology
which
> > runs on TCPIP. We have over 2500 pcs in our user base using wired
networks
> > who are having no networking problems (we would be out of business if
our
> > application was having problems with general networking).
> >
> > All customers who have tried wireless to date have stopped using it due
to
> > various reasons. This particular customer is adamant that it is our
> > application and can't even accept that is MAY be the network. In ODBC I
> > have
> > adjusted the "timeout" period in seconds from 5 seconds to 30 seconds
> > which
> > means that our app will not throw up a message until that time has
> > expired.
> > I did this about a week ago and he is now saying that the app now
freezes
> > and still drops out as well. The freezing to me is consistent with the
> > timeout period being increased.
> >
> > The wireless encryption is not enabled as our app drops out heaps more.
> > The
> > site has concrete walls and it is a Dental surgery so I can see the
> > potential for interference. The router is a Belkin and I am unsure of
the
> > standard. It is not recent, is he ha had is for about 1 year.
> >
> > Can anybody help with the following:
> > 1. General advise on this topic.
> > 2. Any website or other info.
> > 3. Links to info on how to optimize software so that is more compatible
> > with
> > wireless.
> >
> > Thanks, any help much appreciated.
> >
> > Regards
> > David
> >
> >
>
>

Thanks for the reply. I did think it is the latency issue as well. If I
find any resources I will forward them.


Regards
David

"Kevin 'Sparty' Broderick" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) om...
> "David Holstein" <(E-Mail Removed)> wrote in message
news:<40ffb4e2$0$27221$(E-Mail Removed). com.au>...
> > Hi,
> >
> > Has anybody had any experience with database software on wireless
networks.
> [CHOMP]
> > Can anybody help with the following:
> > 1. General advise on this topic.
> > 2. Any website or other info.
> > 3. Links to info on how to optimize software so that is more compatible
with
> > wireless.
>
> I'd be quite interested in 2 and 3, myself; the problems I've seen running
> database-backed applications over 802.11b have all been latency-related.
> In other words, the bandwidth available is never saturated (I've seen
200Kb/s
> without complaints in throughput, while there have been problems where the
> actual throughput was peaking under 30Kb/s), but sometimes data takse too
> long to get from point A to point B. With a Micros 3700 POS system, we
didn't
> have any trouble over a 22 Mbps (theoretical) connection for one of the
kitchen
> terminals in one location, yet when we relocated it to another on-site
kitchen,
> performance was intermittantly abysmal or nonexistant, while sometimes
also
> being quite decent. The distance the signal had to travel was about the
same
> in both cases, as was the hardware involved; the only differences were
> interference (different devices nearby) and walls (different building, God
only
> knows what construction differences). Since I ran Cat5 to the new
location,
> the terminal has worked quite well.
>
> Another application we have would do file-based inter-program
> communication (i.e. product A writes a request, via SMB/CIFS, to
> a specified directory on server B, which is running product B;
> product B then reads, renames, and acts on that request file);
> the request file would apparently get written but the client making
> the request didn't think it worked due to the network latency,
> at which point it would (apparently) check existence, note that the
> file was not present on the server, and re-write it. The problem, of
> course, was that the server was already acting on it and would then
> treat the second request file as a new request, acting on it as well.
> This we observed both as a significant problem on a 11Mbps point-
> to-point wireless link and as an even more significant problem via
> a VPN connection; the workaround was to change the way the client
> application wrote the request file, shelling out of VB and asking
> xcopy to move the file rather than opening the request file as a file
> object directly.
>
> As I said, I'd be very interested in more resources on the subject;
> the troubleshooting we did with the file-latency issue seems to
> suggest that it's actually a relatively low-level Windows Networking
> (both the server and the client were Windows boxen) issue with
> high-latency links if the newly-written file is quickly deleted or
> moved by another process accessing the server.

David,

Test by all means, but I doubt very much that OLE DB will do anything
different. After all under the hood many implementations of OLE DB use
ODBC - I am forgetting that you are using Sybase, but I expect it will be
much the same as MS SQL Server (due to their shared heritage).

Your observation that the link hangs if you increase some timeout indicates
to me that it is a network connection problem. There are two timeouts for
ODBC: Login and Query - their use and difference is quite obvious. If you
set query timeout to 0 = infinite then the client end will wait forever for
queries to finish. If this happens intermittently and runnning the Sybase
equivalent to SQL Server Profiler shows that the queries themselves are not
intermittent then you have some evidence that it is the link itself. Some
ping testing running at the same time would hammer home that it is the link.

If you have a link that is so intermittent (if) then there is little you can
do from an application coding perspective other than reducing the number of
interactions with the server, not using cursors (IE using firewall cursors
instead, using stored procedures for 'actions' and so on). If you think
about the more modern techniques for such situations where the client runs
largely disconnected, then again, when they connect the same issues will
occur and the system will still be hosed. So even though there is some merit
in re-coding using a Web Service or Disconnected Application .Net style
architecture as mentioned, it will not solve the problem.

From an application coding perspective you can improve things by using
stored procedures, firehose cursors to fetch data, not using server side
cursors, generally architecting for maximum performance. There are many
techniques that became normal (for me at least) in using ODBC & SQL Server
that were obscure / poorly documented / not highlighted in programming
literature that are now normal in .Net - IE those things I have just
referred to. They all amount to doing everything with least impact on the
server and network, and often having to do some extra coding to cater for
such as using arrays to hold records retrieved by firehose cursors keeping
in mind always the need for up to date data (EG stock or account balances,
pricing etc) record locking, and so on.

My recommendation would be to solve the lack of reliability in the wireless
connections first and establish / publish reliability levels which your
business requires to be attained before your system will be supported in
such an environment. If a wireless network does not meet those standards of
reliability (EG a 24 hour ping test with all responses within x% of norm)
then your justification is simple: "There is no point in having a Network
unless it works properly". Sounds a little harsh, but you could spend weeks
on this and end up fixing their networking issues simply because they refuse
to run a bit of cat5.

Post back if you want to follow up on this.

HTH
- Tim




"David Holstein" <(E-Mail Removed)> wrote in message
news:4104bc7c$0$27241$(E-Mail Removed) om.au...
> Yes, what you are saying is right. It is a 'thick' client using ODBC. I
> will
> look at test scenario and also OLEDB.
>
>
> Regards
> David
>
> "Jeroen van Bemmel" <(E-Mail Removed)> wrote in message
> news:d29a7$41000243$513bab05$(E-Mail Removed) ...
>> If I understand correctly your application consists of a server database
>> with a 'thick' client that makes ODBC connections to it.
>>
>> My advice would be to get a wireless setup in your lab yourself and use
> that
>> for testing
>>
>> A simple test could be to see how your app handles an ethernet cable
>> being
>> unplugged, but that's not the same as the WLAN connection behavior
>>
>> A more robust solution would be to redesign your application to be less
>> dependent on long-lived connections, but that's probably a lot of effort.
>> Maybe tweaking of TCP settings could alleviate the problem a bit
>>
>> Also, I found several sources on the Internet stating that using OLEDB
>> directly instead of ODBC could improve robustness and performance
>>
>>
>> "David Holstein" <(E-Mail Removed)> wrote in message
>> news:40ffb4e2$0$27221$(E-Mail Removed) om.au...
>> > Hi,
>> >
>> > Has anybody had any experience with database software on wireless
>> > networks.
>> > I have a customer who is saying that our application drops out 3 - 4
> times
>> > a
>> > day. We use Sybase 7.0 which is a stable, robust database technology
> which
>> > runs on TCPIP. We have over 2500 pcs in our user base using wired
> networks
>> > who are having no networking problems (we would be out of business if
> our
>> > application was having problems with general networking).
>> >
>> > All customers who have tried wireless to date have stopped using it due
> to
>> > various reasons. This particular customer is adamant that it is our
>> > application and can't even accept that is MAY be the network. In ODBC I
>> > have
>> > adjusted the "timeout" period in seconds from 5 seconds to 30 seconds
>> > which
>> > means that our app will not throw up a message until that time has
>> > expired.
>> > I did this about a week ago and he is now saying that the app now
> freezes
>> > and still drops out as well. The freezing to me is consistent with the
>> > timeout period being increased.
>> >
>> > The wireless encryption is not enabled as our app drops out heaps more.
>> > The
>> > site has concrete walls and it is a Dental surgery so I can see the
>> > potential for interference. The router is a Belkin and I am unsure of
> the
>> > standard. It is not recent, is he ha had is for about 1 year.
>> >
>> > Can anybody help with the following:
>> > 1. General advise on this topic.
>> > 2. Any website or other info.
>> > 3. Links to info on how to optimize software so that is more compatible
>> > with
>> > wireless.
>> >
>> > Thanks, any help much appreciated.
>> >
>> > Regards
>> > David
>> >
>> >
>>
>>
>
>

David,

Tim's response makes sense to me, I just wanted to say that the OLE DB thing
was something I picked up from the Internet and not something I have
experience with myself

General recommended approach would thus be:
1) Establish that it is indeed the wireless link causing the problems (and
not e.g. some wrong MTU or other setting in their environment)
2) Determine the conditions under which it occurs in general (e.g. >0.5%
packet loss or link drops)
3) Either make the application more robust against this and/or declare
limits of what you're willing to support

To me 3-4 times a day of a dropping wireless link (that's what it sounds
like, assumption) does not sound extremely unstable as a network, it should
be possible to tweak some settings (probably timing related) to get more
robustness (like you were already trying to do)

Good luck,

Jeroen


"Tim" <(E-Mail Removed)> wrote in message news:ce2l8t$nte$(E-Mail Removed)...
> David,
>
> Test by all means, but I doubt very much that OLE DB will do anything
> different. After all under the hood many implementations of OLE DB use
> ODBC - I am forgetting that you are using Sybase, but I expect it will be
> much the same as MS SQL Server (due to their shared heritage).
>
> Your observation that the link hangs if you increase some timeout
> indicates to me that it is a network connection problem. There are two
> timeouts for ODBC: Login and Query - their use and difference is quite
> obvious. If you set query timeout to 0 = infinite then the client end will
> wait forever for queries to finish. If this happens intermittently and
> runnning the Sybase equivalent to SQL Server Profiler shows that the
> queries themselves are not intermittent then you have some evidence that
> it is the link itself. Some ping testing running at the same time would
> hammer home that it is the link.
>
> If you have a link that is so intermittent (if) then there is little you
> can do from an application coding perspective other than reducing the
> number of interactions with the server, not using cursors (IE using
> firewall cursors instead, using stored procedures for 'actions' and so
> on). If you think about the more modern techniques for such situations
> where the client runs largely disconnected, then again, when they connect
> the same issues will occur and the system will still be hosed. So even
> though there is some merit in re-coding using a Web Service or
> Disconnected Application .Net style architecture as mentioned, it will not
> solve the problem.
>
> From an application coding perspective you can improve things by using
> stored procedures, firehose cursors to fetch data, not using server side
> cursors, generally architecting for maximum performance. There are many
> techniques that became normal (for me at least) in using ODBC & SQL Server
> that were obscure / poorly documented / not highlighted in programming
> literature that are now normal in .Net - IE those things I have just
> referred to. They all amount to doing everything with least impact on the
> server and network, and often having to do some extra coding to cater for
> such as using arrays to hold records retrieved by firehose cursors keeping
> in mind always the need for up to date data (EG stock or account balances,
> pricing etc) record locking, and so on.
>
> My recommendation would be to solve the lack of reliability in the
> wireless connections first and establish / publish reliability levels
> which your business requires to be attained before your system will be
> supported in such an environment. If a wireless network does not meet
> those standards of reliability (EG a 24 hour ping test with all responses
> within x% of norm) then your justification is simple: "There is no point
> in having a Network unless it works properly". Sounds a little harsh, but
> you could spend weeks on this and end up fixing their networking issues
> simply because they refuse to run a bit of cat5.
>
> Post back if you want to follow up on this.
>
> HTH
> - Tim
>
>
>
>
> "David Holstein" <(E-Mail Removed)> wrote in message
> news:4104bc7c$0$27241$(E-Mail Removed) om.au...
>> Yes, what you are saying is right. It is a 'thick' client using ODBC. I
>> will
>> look at test scenario and also OLEDB.
>>
>>
>> Regards
>> David
>>
>> "Jeroen van Bemmel" <(E-Mail Removed)> wrote in message
>> news:d29a7$41000243$513bab05$(E-Mail Removed) ...
>>> If I understand correctly your application consists of a server database
>>> with a 'thick' client that makes ODBC connections to it.
>>>
>>> My advice would be to get a wireless setup in your lab yourself and use
>> that
>>> for testing
>>>
>>> A simple test could be to see how your app handles an ethernet cable
>>> being
>>> unplugged, but that's not the same as the WLAN connection behavior
>>>
>>> A more robust solution would be to redesign your application to be less
>>> dependent on long-lived connections, but that's probably a lot of
>>> effort.
>>> Maybe tweaking of TCP settings could alleviate the problem a bit
>>>
>>> Also, I found several sources on the Internet stating that using OLEDB
>>> directly instead of ODBC could improve robustness and performance
>>>
>>>
>>> "David Holstein" <(E-Mail Removed)> wrote in message
>>> news:40ffb4e2$0$27221$(E-Mail Removed) om.au...
>>> > Hi,
>>> >
>>> > Has anybody had any experience with database software on wireless
>>> > networks.
>>> > I have a customer who is saying that our application drops out 3 - 4
>> times
>>> > a
>>> > day. We use Sybase 7.0 which is a stable, robust database technology
>> which
>>> > runs on TCPIP. We have over 2500 pcs in our user base using wired
>> networks
>>> > who are having no networking problems (we would be out of business if
>> our
>>> > application was having problems with general networking).
>>> >
>>> > All customers who have tried wireless to date have stopped using it
>>> > due
>> to
>>> > various reasons. This particular customer is adamant that it is our
>>> > application and can't even accept that is MAY be the network. In ODBC
>>> > I
>>> > have
>>> > adjusted the "timeout" period in seconds from 5 seconds to 30 seconds
>>> > which
>>> > means that our app will not throw up a message until that time has
>>> > expired.
>>> > I did this about a week ago and he is now saying that the app now
>> freezes
>>> > and still drops out as well. The freezing to me is consistent with the
>>> > timeout period being increased.
>>> >
>>> > The wireless encryption is not enabled as our app drops out heaps
>>> > more.
>>> > The
>>> > site has concrete walls and it is a Dental surgery so I can see the
>>> > potential for interference. The router is a Belkin and I am unsure of
>> the
>>> > standard. It is not recent, is he ha had is for about 1 year.
>>> >
>>> > Can anybody help with the following:
>>> > 1. General advise on this topic.
>>> > 2. Any website or other info.
>>> > 3. Links to info on how to optimize software so that is more
>>> > compatible
>>> > with
>>> > wireless.
>>> >
>>> > Thanks, any help much appreciated.
>>> >
>>> > Regards
>>> > David
>>> >
>>> >
>>>
>>>
>>
>>
>
>

On Mon, 26 Jul 2004 17:29:38 +0200, "Jeroen van Bemmel"
<(E-Mail Removed)> wrote:

>General recommended approach would thus be:
>1) Establish that it is indeed the wireless link causing the problems (and
>not e.g. some wrong MTU or other setting in their environment)
>2) Determine the conditions under which it occurs in general (e.g. >0.5%
>packet loss or link drops)
>3) Either make the application more robust against this and/or declare
>limits of what you're willing to support

Good approach to identifying the problem. You can simulate network
traffic impairments on a wired network. I use DummyNet.
http://info.iet.unipi.it/~luigi/ip_dummynet/
It can do queue depletion, multipath simulation, bandwidth
constriction, traffic constipation, random packet loss, and general
havoc. It's amazing how many applications roll over and die when
faced with traffic impairments. I use it for link simulation and
optimizing performance parameters. Put a DummyNet box between a
client workstation and the Sybase server and watch the "high
availability" database hiccup and die. (My idea of fun).

However, all the discussion about making the database application more
"robust" is IMHO a poor way to compensate for potentially flaky
wireless hardware. If the wireless part worked as expected, then
there would be no problem. The original question included casual
mention that some Belkin access point was being used and that ALL
customers were experiencing problems. Do all customers have Belkin
access points? I've had some problems with one Belkin 802.11b router
(forgot model number) that could not be cured. The symptoms was that
it did not appreciate small packets as found in my telnet sessions.
Something in the 802.3 encapsulation mechanism was amiss for small
packets only. I don't know if these are related to the current
problem, but a change of access point might improve the situation and
salvage the irate customer. (Diagnosis by substitution).

Also, in cases of unreliability, I try to do a site survey, preferably
with a spectrum analyzer. It's amazing what you find spewing RF in
the 2.4GHz band. Even the best hardware will not work in interference
infested areas. Tall glass buildings with a gorgeous view methinks
are the worst.

Cheap spectrum analyzer (that doesn't work with XP):
http://cgi.ebay.com/ws/eBayISAPI.dll...tem=5711724206


--
Jeff Liebermann (E-Mail Removed)
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 AE6KS 831-336-2558

I was just thinking......

A handy test may be to write an application that uses odbc to open a
recordset and MoveNext say once per second or ten in an extremely large
table. Immediately prior to each MoveNext, a timer is activated (say a 1
second timer). Immediately after the MoveNext finishes synchronously the
timer is killed. If the timer actually triggers then possibly interference
is occuring, so ShellExecute (or System or whatever in your favourite
language) a "ping <addresss> >> c:\diags\Diag yyyymmdd hhnnss.txt" file this
way you will capture the pings from within 1 second (or less if you prefer)
of something ODD happening. If the ping shows no answer, or very long trip
times then this is strong evidence that odbc issues are network issues -
which I don't doubt anyway.

Personally, there are some makes of products that I will never purchase. If
I see a product on the shelf at certain big name shops I know they are on
the shelf for their profitability not their quality. Oddly, I have had
little trouble with a lot of DSE stuff (EG SCSI 2 controllers better than
adpatec ones for 1/4 the price).

- Tim






"Jeff Liebermann" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> On Mon, 26 Jul 2004 17:29:38 +0200, "Jeroen van Bemmel"
> <(E-Mail Removed)> wrote:
>
>>General recommended approach would thus be:
>>1) Establish that it is indeed the wireless link causing the problems (and
>>not e.g. some wrong MTU or other setting in their environment)
>>2) Determine the conditions under which it occurs in general (e.g. >0.5%
>>packet loss or link drops)
>>3) Either make the application more robust against this and/or declare
>>limits of what you're willing to support
>
> Good approach to identifying the problem. You can simulate network
> traffic impairments on a wired network. I use DummyNet.
> http://info.iet.unipi.it/~luigi/ip_dummynet/
> It can do queue depletion, multipath simulation, bandwidth
> constriction, traffic constipation, random packet loss, and general
> havoc. It's amazing how many applications roll over and die when
> faced with traffic impairments. I use it for link simulation and
> optimizing performance parameters. Put a DummyNet box between a
> client workstation and the Sybase server and watch the "high
> availability" database hiccup and die. (My idea of fun).
>
> However, all the discussion about making the database application more
> "robust" is IMHO a poor way to compensate for potentially flaky
> wireless hardware. If the wireless part worked as expected, then
> there would be no problem. The original question included casual
> mention that some Belkin access point was being used and that ALL
> customers were experiencing problems. Do all customers have Belkin
> access points? I've had some problems with one Belkin 802.11b router
> (forgot model number) that could not be cured. The symptoms was that
> it did not appreciate small packets as found in my telnet sessions.
> Something in the 802.3 encapsulation mechanism was amiss for small
> packets only. I don't know if these are related to the current
> problem, but a change of access point might improve the situation and
> salvage the irate customer. (Diagnosis by substitution).
>
> Also, in cases of unreliability, I try to do a site survey, preferably
> with a spectrum analyzer. It's amazing what you find spewing RF in
> the 2.4GHz band. Even the best hardware will not work in interference
> infested areas. Tall glass buildings with a gorgeous view methinks
> are the worst.
>
> Cheap spectrum analyzer (that doesn't work with XP):
> http://cgi.ebay.com/ws/eBayISAPI.dll...tem=5711724206
>
>
> --
> Jeff Liebermann (E-Mail Removed)
> 150 Felker St #D http://www.LearnByDestroying.com
> Santa Cruz CA 95060 AE6KS 831-336-2558