>
> >>*) Q: Should vrml server/client compress/decompress, or should the lan/wan?
> >> I note that many modems, 14.4 & ISDN, offer compression ... which works
> >> for text, but not for gif's. Once something is compressed, it can't be
> >> compressed further. So shipping compressed vrml over an isdn modem only
> >> ends up chewing through more client-cpu time, without offering any actual
> >> transmission benefit. So maybe vrml should punt, and let the network
> >> equipment do its job?
>
> I also note that at least on the ISDN side, there is a lot of
> incompatible equipment out there, so whether you actually get
> compression or not depends on whether or not you own the same
> brand name as your internet provider.
>
> I don't really know how compatbile all those v.whatever modems are,
> and whether they really do kick into compressed mode. My own 14.4
> modem never seems to get above 11 kbits/sec during anon ftp.
I typically see 1.1 to 1.35 over PPP to my provider when I download from
my shell account's area. further away will of course be slower, and
doing multiple things will of course slow the backgound ftp session. what
do you get doing a straight dial in and z-modem? if you get less than
1600 cps then check your modem settings.
>
> Note also, gzip offers benefits even on ethernet segments ...
> and saves file space to boot.
>
compressing the file ahead of time saves ONLINE time, and DISKSPACE, and
depending on the compression program and data being comprressed, can
acheive GREATER compression than v.42bis can. v.42bis will max out around
4 to 1 and I've seen files compressed to 3% of their original size (33 to
1). so use what seams to work best.