1. Home
  2. Point-Of-Sale Software
  3. 401 hell!

401 hell!

We have a 3gb HQ db with 6 stores. Whenever a 401 needs to send a large amount of data to HQ, the following happens:

HQ spikes all 8 CPUs at 100% for about 40 minutes then completes Store HQ client times out, never registers that the 401 completed Next time the store connects, same thing happens again until I delete the

401 in question.

This is a major problem, because when we do a physical inventory, we need to do all sorts of gyrations to ensure that the data is uploaded and the offending 401 is then removed.

It's really not all that much data, what is it with the RMS db design that makes this SO INEFFICIENT?? I mean 50 thousand DB record updates is routine for many systems.

I have been working with MS support on this and the support tech claims it is "working" because it works when the store DB and HQ db reside on the same machine. This is true but that's not a real world scenario. They want to blame our net connection. Plenty of apps run just fine on DSL lines (this one has 0.00% packet loss)

I seem to have hit a dead end with MS support, can anyone shed some light on this?

Reply to
Daniel S.
Loading thread data ...

Daniel,

I don't know a thing about the POS software, I've just been reading this group so I can help my BIL decide on software for his new store. That said, I may be able to offer a suggestion. You probably don't want to hear this but I would agree with MS about it being a network problem. Rather than me typing all the instructions, I'll provide some links for you to look at and then do some tests.

Your DSL line4 may "appear" to work perfectly with a normal traffic load but once you start to stress it, things begin to go to hell. Start by testing the MTU (max transmission unit). You can change the MTU and then stress test it yourself to see that an incorrect MTU setting (below max) still works and no packet loss until you load it down.

formatting link
formatting link
The next site is a good tutorial on ATM

formatting link
In short, ATM can be extremely difficult to test and you should contact your provider when you feel you've done everything you can internally to eliminate your hardware and wiring.

Bob S.

Reply to
BobS

Scratch that first link.... and use this one. Sorry. But just in case you do click on it, that is one helluva guitar player.

formatting link

Bob S.

Reply to
BobS

Thanks for the link. I checked the MTU and found the max from the ping util to be 1464. The router max was set to 1500. . . There was no MTU set in the registry for the LAN adapter. Your post may well have been the solution.

Prior to reading your post, I ended up using a PPTP VPN with the RAS funtionality in HQclient, and changing the HQ server address to it's lan address.

So basically the HQclient now 'dials in' to the HQ VPN then initiates HQ comms through the VPN tunnel.

This seems to work.

Now if I could just find out why it takes 40 minutes to update 50k items on an 8 core 2ghz Xeon box with 4gb RAM. . .

"BobS" wrote:

Reply to
Daniel S.

You are right that transfering this amount of data over a DSL line is nothing. I have the same concerns about the processing. However, I was able to get around this be scheduling more frequent 401's. I went from hourly to every 10 minutes and all is well. Of course, it eats up log space quickly and I have to delete old completed worksheets every couple of weeks.

Reply to
Jason

BeanSmart website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.