Re: [SLUG] gunzip 1.3G file over ssh - crawling
On Sat, 2006-02-25 at 07:35 +1100, amanda wynne wrote: What if you use scp to get the compressed file to your end first. This is an image of an NTFS partition (Windows XP) for a dual boot PC. I presume this is a regular backup. How much of that 8GB actually changes No, I should have clarified what it was. Thanks for your comments. -- Simon Wong [EMAIL PROTECTED] -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Hunting an IP Address.
Don't know if this helps but you can check the details of the IP address provider, and provider contact details here: http:// www.whois.sc/210.50.159.126 Cheers, Shane. On 20/02/2006, at 10:47 PM, Simon Males wrote: Start off with abuse@ispname.com.au If no luck, contact whoever deals with there TIO complaints. -- Simon Males [EMAIL PROTECTED] Kevin Fitzgerald wrote: Hi All I have a customer who has had something rather villifying written about them on their own Messageboard and they want to persue it legally. They have asked me to chase down the IP Address and I'm not suer where to start. I know the IP, 210.50.159.126 I assume this will have been assigned to a User by an ISP How do I find that out? Then I will contact the ISP and, with legal help and advice of course, try and find the User who was assigned that address at the time of the writing. If any slugers out tthere can point me in the direction of where to start I would be most appreciative. Regards Kev - Kevin Fitzgerald TCG TECHNOLOGIES Skype: kevtcg MSN: [EMAIL PROTECTED] Mobile: 0412 404 002 Web: www.tcgtech.com.au -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html Kind regards, Shane Shane MacPhillamy M:+61-4 1923 0983 P:+61-2 4368 2544 -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] ADSL Query
On Sat, February 25, 2006 12:22 pm, [EMAIL PROTECTED] wrote: On Saturday 25 February 2006 09:00, [EMAIL PROTECTED] wrote: Dunno about ISOs. Have you checked TPGs standard ADSL deals? My current one is $50 per month, 1.5Mb down (I get an average of 1.2) and 20G per month. I'm not sure if they've discontinued the deal to new ADSL members...(?) I just got an AAPT offer in the mail: 512, 12GB capped, $39/month, no fixed contract lenght -- Voytek -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
SOLVED Re: [SLUG] gunzip 1.3G file over ssh - crawling
The scenario: Server: Ubuntu Breezy Linux software RAID5 SATAII HDDs Gigabit LAN Client: Knoppix 3.8.2 (Live) (booted with knoppix 2 for cli) Acer Veriton 3500 P4, 256MB RAM, 20GB HDD 100Mbit LAN I have an image of an NTFS partition that I want to be able to write to the client PC (snapshot or deployment to identical hardware). More below, thanks to Glen... On Fri, 2006-02-24 at 13:41 +0100, Glen Turner wrote: That first 1GB is the oddity. It's just some buffers filling. The results after that are the real results where buffering no longer gives an advantage and you see the true sustained (lack of) throughput. OK. That would indicate that you're filling the bus to the hard disk, not the network between the CPUs. yeah, the network throughput (iptraf) was only about 20Mbits, well below what I was expecting for a Gigabit to 100Mbit connection. dd is writing a lot of empty blocks down to that disk. You might want to consider using tar is the filesystem has a lot of empty space. True, I should have elaborated that this was an NTFS partition image. That's a very handwaving question since you haven't told us anything about the computer. The bottleneck obviously varies with the hardware. Sorry, that's the sort of question you get from someone when they're stuck :-) Now set the machine for maximum performance. hdparm should report 32b UDMA, write caching, look ahead, APM disabled, fast AAM goodness. TCP buffers should BINGO! Thank-you, thank-you, thank-you! I didn't think about DMA :-( I assumed that Knoppix would turn on such things for me! (1) Turning on DMA (hdparm -d1 /dev/hda): On the client: # time ssh [EMAIL PROTECTED] cat client.img.gz | gunzip /dev/hda1 time reports a real time of 6 mins 1.8s (including ssh password entry)! There's still a slow down at the 1GB mark for about 12 seconds, then full speed transfer is reached for another 200MB or so, after that the transfer trickles along until the end of the file. So, if I get the partition image size as close to or below that 1GB mark things are as fast as they're gonna get. (2) Tuning with hdparm So this time I tried: # hdparm -d1 -c1 /dev/hda time reported basically the same time within a few seconds. Performance was the same. (3) Netcat I thought I would try netcat. Server: $ cat image.img.gz | nc -l -p 5030 -q 10 Client: # time nc serverip 5030 | gunzip /dev/hda1 time reports real time of 5m18s. Wow! Buffers filled at around 1200MB, another burst at around 1400MB but then crawling (270kbits/sec) to the end. Test. Are you CPU-bound, I/O-bound or network bound (top, vmstat, etc)? If you are, is that bound reasonable (eg, 90% of the sustained disk write rate)? So, in the end definately disk I/O bound. You might want to try transferring from and to /dev/null to check network+CPU preformance. Note that ssh has a special Alrighty then, netcat to /dev/null. time gives real 2m50s. performance issue -- it uses a 128MB window so the bandwidth- delay product needs to be under that for ssh to run at maximum speed. Not sure where to tune that. I'll put that aside for now. Now you're found the bottleneck, fix it. Repeat test until one of the hard bounds is reached. If possible, chose a better method to move away from that bound (eg, dd v tar; ssh v ftp of of a gpg-encrypted file). hence netcat instead of ssh. Since, this is now happening within a reasonable length of time here's some more results: 1. Netcat + dd nc serverip 5030 | gunzip | dd of=/dev/hda1 time gives real 5m52s. So quite a bit slower than the redirect. Remember to record your results at each step. Let us know the interesting numbers (eg, what is the real throughput of your particular drive). There's surprisingly few real benchmarks out there, so you'll be helping a lot by posting your numbers. Well, thanks so much for your help Glen. I really appreciate your teach a man to fish support :-) I hope the above results are of use to anyone else needing to do the same sort of thing. I think I'll try and get that partition image size down (bye bye system restore). Of course, for linux clients this is so much easier (no activation issues) so setting up the preseed file for Ubuntu is my next step. Thanks again, have a great day! -- Simon Wong [EMAIL PROTECTED] -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: SOLVED Re: [SLUG] gunzip 1.3G file over ssh - crawling
This one time, at band camp, Simon Wong wrote: # time ssh [EMAIL PROTECTED] cat client.img.gz | gunzip /dev/hda1 time reports a real time of 6 mins 1.8s (including ssh password entry)! There's still a slow down at the 1GB mark for about 12 seconds, then full speed transfer is reached for another 200MB or so, after that the transfer trickles along until the end of the file. (3) Netcat I thought I would try netcat. Server: $ cat image.img.gz | nc -l -p 5030 -q 10 Client: # time nc serverip 5030 | gunzip /dev/hda1 time reports real time of 5m18s. Wow! I was going to suggest using netcat, or disabling compression in SSH, because you're sending over a gzipped image so you might have experienced some slowdown (maybe the 50s difference between ssh and netcat) due to SSH compression maybe actually increasing the amount of data transmitted. -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: SOLVED Re: [SLUG] gunzip 1.3G file over ssh - crawling
On Sun, 2006-02-26 at 14:19 +1100, Jamie Wilkinson wrote: I was going to suggest using netcat, or disabling compression in SSH, because you're sending over a gzipped image so you might have experienced some slowdown (maybe the 50s difference between ssh and netcat) due to SSH compression maybe actually increasing the amount of data transmitted. perhaps one to try another time. I also tried to use my external USB DVD drive with Knoppix to see how fast it could do it over USB2 but I couldn't get my drive recognised. Things are fast enough now to be manageable anyway now. -- Simon Wong [EMAIL PROTECTED] -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] SMB network printer
Has anyone suggested this website? http://www.linux-printing.org/ --- Julio Cesar Ody [EMAIL PROTECTED] wrote: Hi all, I'm looking into buying a networked printer, and I wanted to know if anyone can share some advice on a good one. It has to work by itself, with a built-in printing server which is Windows compatible and usable by GNU/Linuxes via Samba. Any help is appreciated. Thanks. -- Julio C. Ody http://rootshell.be/~julioody -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html Do you Yahoo!? Find a local business fast with Yahoo! Local Search http://au.local.yahoo.com -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: SOLVED Re: [SLUG] gunzip 1.3G file over ssh - crawling
On Sun, 2006-02-26 at 13:07 +1000, Simon Wong wrote: Since, this is now happening within a reasonable length of time here's some more results: 1. Netcat + dd nc serverip 5030 | gunzip | dd of=/dev/hda1 time gives real 5m52s. So quite a bit slower than the redirect. dd has a default read size of 1 byte. Try bs=4192 or something similar. It makes a /huge/ difference. Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
