i suppose it's lockin -  the alternative program(s) would need to import

appointments, financials, as well as clinical . also , need to test if the big troublesome

records do any better in the alternative, as ctrl-alt-delete and looking at the

network performance monitoring chart on windoze shows that the network bandwidth

is 25% occupied for the time the md client is stuck waiting for the record to open,

which seems to support the idea that it's the network that is the bottleneck

(why 25 % , anyone know ?),  and that its solvable either by ugrading the

network bandwidth, or reducing the amount of data need to be transferred

(e.g. by using the RDP protocol for thin client efficient pixel transfer - it's just

efficient gui changes across the network, isn't it, ie that winconnect thing;

apparently its a RFC, so it's not windows specific , what is it ? )

is there a linux alternative for thin clients , e.g. X window system, and a windows

emulator , and using a common data directory in wine with md2  ( how is the

atomic multi-user operation on shared files handled in md2 ? file locking ?  )



On Thu Mar 30 9:48 , Elizabeth Dodd sent:

On Thu, 30 Mar 2006 11:57, [EMAIL PROTECTED] wrote:
> the original question is, can it be guaranteed that you get a performance
> improvement by upgrading a network from 100 bit to gigabit,
nothing is guaranteed. using md2 doesn't sound sensible if you need this
improvement - going to a real program would give you the biggest speed
improvement

> how much would
> it cost,
not sure (I'm asking the pro here)
> can you use existing cabling,
can run on CAT5E for short distances, longer distances are slower.
> and can you do it just by replacing
> the switch, and network cards at each computer ?
got to do that.
just putting in a gigabit switch and a gigabit card in each server would allow
an improvement

>

--
Just because the message may never be received does not mean it is
not worth sending.
_______________________________________________
Gpcg_talk mailing list
[email protected]
http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk


_______________________________________________
Gpcg_talk mailing list
[email protected]
http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk

Reply via email to