David More <[EMAIL PROTECTED]> wrote: > > Hi Tim, > > I would check the spec of your Optus Cable connection. > > I think you will find upload is limited to 256kbits/sec > > Downloads are dependent on where you are, how many you share your cable > loop with etc > > Here is the rate table > > Easy Start Up to 9,900kbps/128kbps 100MB 100MB + 200MB 'yes' > Data > $29.95 $19.95 > Light Up to 9,900kbps/128kbps 300MB 300MB + 600MB 'yes' > Data $39.95 > $29.95 > Sprint Up to 9,900kbps/128kbps 2GB 2GB + 4GB 'yes' Data > $49.95 > $39.95 > Advantage Up to 9,900kbps/256kbps 7 GB 7GB + 14GB 'yes' Data > $59.95 > $49.95 > Power Up to 9,900kbps/256kbps 20GB 20GB + 40GB 'yes' Data > $79.95 > $69.95
Hmm, I always though the cable (which is completely different technology to the more common ADSL or ADSL2 "broadband" connection) provided symmetrical speed - but I may hve been mistaken. Some quick calculations reveals that 256kbps is almost exactly 15MB in 10 minutes, which is what I observed, so you may be correct. I try some uploads from elsewhere and see what speeds are possible. Tim C > On Mon, 03 Apr 2006 08:27:04 +1000, Tim Churches wrote: > > Tim Churches wrote: > >> Amazon S3 may be of interest to subscribers to this list, both > software developers and > end- > >> users. > >> > >> Here is the blurb from the S3 Web page at > >> > http://www.amazon.com/gp/browse.html/104-1570532-7764752?node=16427261 > >> > > .. > >> Lots of things, but a few things spring immediately to mind. > >> > >> 1) Off-site secondary storage of back-up files for practices or > clinics running their > own EMR > >> systems or other clinical applications on locally-hosted servers. The > advantage of the > simple > >> API provided by S3 is that the EMR/clinical application for a > practice/clinic could > automate > >> the back-up-and-copy-to-S3 cycle, and could even automate periodic > test retrievals and > restores > >> (to a separate test database or file system on the clinic's EMR > server). I wouldn't > trust the > >> Amazon assurances of privacy for the data (as Amazon are still > subject to US search > warrants > >> and court orders for example, as well as simple security blunders - > so any patient data > would > >> need to be strongly encrypted before sending it to S3 for off-site > backup storage - but > that > >> should be routine practice for any off-site back-ups of patient data > on removable or > >> transportable media anyway). The cost structure for the S3 service > would make such use > very > >> cheap, since the back-up data are sent once and would be rarely > accessed, so the > bandwidth > >> charges should be quite modest, and the per-month storage charges are > very cheap. Cheap > enough > >> for even small clinics in developing and transitional countries to > afford, assuming > they have > >> broadband Internet access to enable the upload of back-ups to S3 in > the first place. > Certainly > >> cheap enough for even small practices/clinics in rich countries - no > more than $10-$20 > per > >> month I would think, maybe much less. > >> > > > > I had a play with Amazon S3 over the weekend. Well, I tried to, > because it was down for > about 22 > > hours from Sat evening to Sunday evening, which puts their claims of > 99.99% uptime in > doubt. > > However, it was only launched two weeks ago so some teething problems > might be expected. > I expect > > they will iron out the bugs and achieve their reliability targets, > eventually. > > > > Anyway, I did manage to store various bits of data and some files on > it, and to get them > back. Of > > primary interest is the transfer speed for large files eg encrypted > backups. I stored a > 15MB > > encrypted file on S3 in 10 minutes. Retrieval took about the same > length of time. > according to my > > online S3 account summary, I now owe Amazon US$0.01 - of course, the > longer I leave the > file > > there on S3, the more I will be charged - US$0.15 per GB per month for > storage - but it > is not > > going to send me to the poorhouse. > > > > The primary issue is the transfer speed. I am using Optus cable, which > uploads and > downloads to > > local Web servers at over 500 kB (kilobytes, not kilobits) per second > - so at full > speed, my 15MB > > upload should have taken just 30 seconds. Thus, the rate-limiting step > seems to be > elsewhere - > > perhaps the speed of the link to the US where the Amazon servers are > located, or perhaps > Amazon > > is throttling upload and download speeds to and from S3 to preserve > their bandwidth. > Anyway, the > > point is that 15MB in 10 minutes is probably what you can expect here > in Oz, regardless > of what > > sort of Internet connection you have (as long as it is not a dial-up > modem). > > > > Is this fast enough to be useful for offsite encrypted back-up copies? > Well, its fast > enough for > > our purposes, which is backup storage of encrypted ad hoc public > health outbreak data > collections > > which are often collected "on the road". But for a 3 or 4GB practice > backup? Let's see, > 15MB in > > 10 minutes equates to 3GB in 50 hours. > > > > Hmmm, that effectively rules it out for offsite GP encrypted backup > copies. Pity. I'll > continue > > to collect data points on transfer speed. Perhaps the forthcoming > Google Gdrive and the > start-up > > OmniDrive online data storage services, which are expected to be > priced similarly but > which may > > have servers located in Australia, will be much faster. We'll see > when they are > available. I > > still think that Amazon S3 might be of interest to radiology practices > wishing to > provide a cheap > > store-and-forward facility to clients for their digitised image files, > which tend to be > rather > > large and thus not well suited to SMTP-based (email) transport - > without either party > needing to > > run 24x7 Web services (Amazon S3 does that for you and both the sender > and receiver of > an image > > file would just act as clients to it). It would also work very nicely > as a > store-and-forward > > facility for interchange of HL7 messages - Amazon S3 would effectively > be the > unintelligent data- > > store-and-retrieve middleman - but gee, they don't charge much - I > suspect that the bill > for even > > a large path lab might only be a few tens of dollars per month. Some > open source code to > add the > > smarts and encryption at the sending and receiving ends and you have > the makings of a > very cheap > > but potentially very robust secure health data exchange service with > an architecture > rather > > similar to that offered by Healthlink etc, but with negligible > per-message costs. Add > Google and > > OmniDrive into the picture as alternative unintelligent > data-store-and-retrieve > middlemen, which > > the client software could automatically fall back to and you would > really have > something. There's > > a business opportunity there for someone or some group to, um, make > almost no money at > all, but > > to receive accolades heaped upon their head(s). > > > > Tim C > > > > _______________________________________________ > > Gpcg_talk mailing list > > [email protected] > > http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk > > > > __________ NOD32 1.1467 (20060402) Information __________ > > > > This message was checked by NOD32 antivirus system. > > http://www.eset.com _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
