A few days ago we discovered that the server that was hosting the Terminal
Server sessions was experiencing CPU failures on one of its two CPUs.
We pulled the hard drives and moved them to a new server.
We haven't had any problems since then.
Tony
Anthony Schmidt
President
The Computery Ltd.
One East Main Street
Bay Shore, NY 11706
Voice 631-665-8100
Fax 631-969-5988
|---------+---------------------------->
| | Anthony Schmidt |
| | |
| | 12/13/2001 08:30 |
| | PM |
| | |
|---------+---------------------------->
>--------------------------------------------------------------------------------------------------------------------------------------------|
|
|
| To: [EMAIL PROTECTED]
|
| cc:
|
| Subject: RE: Terminal Server 2000 and RBase 6.0(Document link: Anthony
Schmidt) |
>--------------------------------------------------------------------------------------------------------------------------------------------|
Lucas:
We've been testing a similar configuration for the last few months (RBW and
RBD 6.5++ on the user stations running Win95, NT, and W2K Pro and on W2K
Terminal Server sessions). When the server is used solely as a file server
it does run more slowly in multi-user mode than in single-user mode but
performance is still acceptable. (Multi-user mode was always slower than
single-user mode all the way back to RBSystemV - concurrency support puts
an expected hit on performance and is normal.)
Our Terminal Server sessions run at lightning speed. I always prefer to do
my development work in a Terminal Server session rather than on a local
copy of the database even though my computer has a 1.8MHz P4 256MB of RAM
and an ATA100 hard drive. The W2K server has dual 933 MHz PIII processors
with 2GB RAM and 10K RPM mirrored SCSI drives. The dual processors really
make a huge difference in performance. I highly recommend using dual
processors on all servers even if all they do is file service.
We have also experienced problems with printing and dropped database
connections for our Terminal Server users. I feel that some of this might
be due to a network component failure. We replaced a suspect network switch
this evening and we'll see if that makes a difference.
I just finished making some pretty hefty updates to a pretty big RB6.5++
database in a Terminal Server sessions on that server after the we replaced
the suspect switch and had no trouble.
We have sent a memory dump to Microsoft from the most recent server crash
to see if they can find the "smoking gun".
If we come up with a solution, I'll post the results to this listserv.
Tony
Anthony Schmidt
President
The Computery Ltd.
One East Main Street
Bay Shore, NY 11706
Voice 631-665-8100
Fax 631-969-5988
|---------+---------------------------->
| | Edwards Lucas |
| | <[EMAIL PROTECTED]|
| | g.au> |
| | Sent by: |
| | owner-rbase-l@son|
| | etmail.com |
| | |
| | |
| | 12/13/2001 07:55 |
| | PM |
| | Please respond to|
| | rbase-l |
| | |
|---------+---------------------------->
>---------------------------------------------------------------------------------------------------------------------------------------------|
|
|
| To: [EMAIL PROTECTED]
|
| cc: (bcc: Anthony Schmidt/BayShore/SGU_LN)
|
| Subject: RE: Terminal Server 2000 and RBase 6.0
|
>---------------------------------------------------------------------------------------------------------------------------------------------|
Yeah, it's totally unbelievable.
At the time it seemed like the most cost effective solution.
And if it wasn't for the fact we have two remote sites where speed is a big
issue,
we would have ditched TS2K months ago.
Lucas
-----Original Message-----
From: Ben Petersen [mailto:[EMAIL PROTECTED]]
Sent: Friday, 14 December 2001 2:29 AM
To: [EMAIL PROTECTED]
Subject: RE: Terminal Server 2000 and RBase 6.0
You have to wonder... the wealthiest, most powerful software
company in the world managed to come up with a server process
that can only handle one connection??
Ben Petersen
On 13 Dec 2001, at 18:12, Albert Berry wrote:
> Our solution to both speed and stability has been to find an old W98SE
box and set it up as strictly an R:Base server. This works well for us.
RBDOS vs W2K is an ongoing test and review situation with PSD Solutions and
RBTI and Microsoft. We, at PSD, raised the issue with MS, and they kindly
installed a test system and db on their network, and verified that our
results are true - W2K servers, with two or more users, suck.
>
>
>
> Edwards Lucas <[EMAIL PROTECTED]> wrote:
>
> >Hi all,
> >
> >About a year ago we took two reasonably fast, very stable RBase for
windows
> >6.0 databases running at separate sites on NT4 servers across two remote
> >LANs, and centralised them, locating them on a Windows2000 Terminal
Server
> >and serving them up across our WAN.
> >This has resulted in two very slow, very unstable databases, loss of
hair,
> >sanity etc...
> >The slowness is a result of lack of bandwith across the WAN (128k ISDN)
and
> >until we go broadband this will be the case.
> >The instablility is a different story.
> >This mainly relates to print jobs, although we are still getting users
> >dumped out of the database for no apparent reason.
> >In most cases when the print job fails:
> >
> >OUTPUT Print.rep
> >WRITE 'PRINT Bla WHERE bla = .bladebla'
> >OUTPUT SCREEN
> >
> >RUN Print.rep
> >ERASE Print.rep
> >
> >it either won't print at all and will dump the user out to the TS
desktop,
> >or it will print but will still dump the user out.
> >
> >Mostly the size of the print jobs are only a few kb, but to print to an
> >700/800/900 series HP deskjet can take an eternity. The HP lasers
5P/6P/2100
> >etc. seem quicker and more reliable but still suffer from the same
problems.
> >At present we have about 70 network printers running off the server
(dual P3
> >733 2Gb ram) and are averaging about 10 RBGTIME sessions and 3 MSACCESS
> >sessions. The users are running a mixture of win95/2000 desktops.
> >
> >We've tried several things including:
> >Making sure the names of the printers are the same at both ends.
> >The local printer ports are set to ECP (HP recommends this).
> >The paper size settings are consistent across client and server.
> >The latest drivers are loaded (windows95 drivers loaded on the server
where
> >needed).
> >Tidying up the code:
> >Being meticulous about declaring/clearing variables.
> >Breaking down the code into smaller procedures.
> >
> >Have been scouring this list for similar problems but it seems that
> >TerminalServer2000 is not a common platform amongst you guys (probably
for
> >good reason).
> >
> >Any help would be very much appreciated.
> >
> >Regards
> >Lucas Edwards
> >Wesley Mission Brisbane
> >
> >
> --
>
>
>
>
> __________________________________________________________________
> Your favorite stores, helpful shopping tools and great gift ideas.
Experience the convenience of
buying online with Shop@Netscape! http://shopnow.netscape.com/
>
> Get your own FREE, personal Netscape Mail account today at
http://webmail.netscape.com/
>
> ================================================
> TO SEE MESSAGE POSTING GUIDELINES:
> Send a plain text email to [EMAIL PROTECTED]
> In the message body, put just two words: INTRO rbase-l
> ================================================
> TO UNSUBSCRIBE: send a plain text email to [EMAIL PROTECTED]
> In the message body, put just two words: UNSUBSCRIBE rbase-l
>
================================================
TO SEE MESSAGE POSTING GUIDELINES:
Send a plain text email to [EMAIL PROTECTED]
In the message body, put just two words: INTRO rbase-l
================================================
TO UNSUBSCRIBE: send a plain text email to [EMAIL PROTECTED]
In the message body, put just two words: UNSUBSCRIBE rbase-l
================================================
TO SEE MESSAGE POSTING GUIDELINES:
Send a plain text email to [EMAIL PROTECTED]
In the message body, put just two words: INTRO rbase-l
================================================
TO UNSUBSCRIBE: send a plain text email to [EMAIL PROTECTED]
In the message body, put just two words: UNSUBSCRIBE rbase-l
