Thread: The good, old times
I am running a postgres update on one of my machines: Downloading Packages: (1/7): postgresql90-plpython-9.0.2-2PGDG.rhel5.x86_64.rp | 50 kB 00:02 (2/7): postgresql90-plperl-9.0.2-2PGDG.rhel5.x86_64.rpm | 51 kB 00:03 (3/7): postgresql90-libs-9.0.2-2PGDG.rhel5.x86_64.rpm | 217 kB 00:14 (4/7): postgresql90-contrib-9.0.2-2PGDG.rhel5.x86_64.rpm | 451 kB 00:40 (5/7): postgresql90-9.0.2-2PGDG.rhel5.x86_64.rpm | 1.4 MB 01:57 (6/7): postgresql90-devel-9.0.2-2PGDG.rhel5.x86_64.rpm | 1.6 MB 02:48 (7/7): postgresql90-se (68%) 44% [===== ] 7.0 kB/s | 2.2 MB 06:33 ETA 7 kilobytes per second??? That brings back the times of the good, old 9600 USR modems and floppy disks.
Mladen Gogala <mladen.gogala 'at' vmsinfo.com> writes: > I am running a postgres update on one of my machines: > > Downloading Packages: > (1/7): postgresql90-plpython-9.0.2-2PGDG.rhel5.x86_64.rp | 50 kB > 00:02 (2/7): postgresql90-plperl-9.0.2-2PGDG.rhel5.x86_64.rpm | > 51 kB 00:03 (3/7): > postgresql90-libs-9.0.2-2PGDG.rhel5.x86_64.rpm | 217 kB 00:14 > (4/7): postgresql90-contrib-9.0.2-2PGDG.rhel5.x86_64.rpm | 451 kB > 00:40 (5/7): postgresql90-9.0.2-2PGDG.rhel5.x86_64.rpm | > 1.4 MB 01:57 (6/7): > postgresql90-devel-9.0.2-2PGDG.rhel5.x86_64.rpm | 1.6 MB 02:48 > (7/7): postgresql90-se (68%) 44% [===== ] 7.0 kB/s | 2.2 MB > 06:33 ETA > > 7 kilobytes per second??? That brings back the times of the good, old > 9600 USR modems and floppy disks. What's your point and in what is it related to that ML? -- Guillaume Cottenceau
On 01/12/2011 10:16 PM, Guillaume Cottenceau wrote: > What's your point and in what is it related to that ML? Given the package names, I suspect this is a poorly-expressed complaint about the performance of downloads from the pgdg/psqlrpms site. If that was the original poster's intent, they would've been better served with a post that included some minimal details like: - Information abut their local connectivity - mtr --report / traceroute output - tests from other available hosts If that wasn't the original poster's intent, perhaps it'd be worth a second try to explain what they were *trying* to say? Was it just a joke - 'cos if so, it was kinda flat. -- Craig Ringer
Craig Ringer wrote: > On 01/12/2011 10:16 PM, Guillaume Cottenceau wrote: > > >> What's your point and in what is it related to that ML? >> > > Given the package names, I suspect this is a poorly-expressed complaint > about the performance of downloads from the pgdg/psqlrpms site. If that > was the original poster's intent, they would've been better served with > a post that included some minimal details like: > Yes, it was a complaint about the download speed. > - Information abut their local connectivity > - mtr --report / traceroute output > - tests from other available hosts > As for the traceroute information, here it is: traceroute yum.pgrpms.org traceroute to yum.pgrpms.org (77.79.103.58), 30 hops max, 40 byte packets 1 216.169.135.254 (216.169.135.254) 0.389 ms 0.404 ms 0.451 ms 2 host189.131.26.216.vmsinfo.com (216.26.131.189) 9.355 ms 9.357 ms 9.368 ms 3 v11.lc2.lou.peak10.net (216.26.190.10) 9.645 ms 9.645 ms 9.637 ms 4 ge-7-41.car1.Cincinnati1.Level3.net (4.53.64.41) 13.002 ms 13.002 ms 13.018 ms 5 ae-2-5.bar1.Cincinnati1.Level3.net (4.69.132.206) 13.101 ms 13.098 ms 13.087 ms 6 ae-10-10.ebr2.Chicago1.Level3.net (4.69.136.214) 22.096 ms 21.358 ms 21.329 ms 7 ae-1-100.ebr1.Chicago1.Level3.net (4.69.132.41) 27.729 ms 10.812 ms 24.132 ms 8 ae-2-2.ebr2.NewYork2.Level3.net (4.69.132.66) 34.008 ms 33.960 ms 34.088 ms 9 ae-1-100.ebr1.NewYork2.Level3.net (4.69.135.253) 34.152 ms 35.353 ms 37.068 ms 10 ae-4-4.ebr1.NewYork1.Level3.net (4.69.141.17) 36.998 ms 37.248 ms 36.986 ms 11 ae-43-43.ebr2.London1.Level3.net (4.69.137.73) 107.031 ms ae-42-42.ebr2.London1.Level3.net (4.69.137.69) 104.624 ms 107.000 ms 12 ae-2-52.edge4.London1.Level3.net (4.69.139.106) 107.506 ms 106.993 ms 180.229 ms 13 (195.50.122.174) 168.849 ms 160.917 ms 161.713 ms 14 static.turktelekom.com.tr (212.156.103.42) 176.503 ms 179.012 ms 179.394 ms 15 gayrettepe-t3-1-gayrettepe-t2-1.turktelekom.com.tr (212.156.118.29) 167.867 ms 167.870 ms 167.862 ms 16 88.255.240.110 (88.255.240.110) 167.515 ms 168.172 ms 165.829 ms 17 ns1.gunduz.org (77.79.103.58) 171.574 ms !X * * [mgogala@lpo-postgres-d01 ~]$ Are there any good mirrors? Apparently, there is something slow in the force. > If that wasn't the original poster's intent, perhaps it'd be worth a > second try to explain what they were *trying* to say? Was it just a joke > - 'cos if so, it was kinda flat. > > -- > Craig Ringer > > -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 http://www.vmsinfo.com The Leader in Integrated Media Intelligence Solutions
On 01/15/2011 12:54 AM, Mladen Gogala wrote: > Yes, it was a complaint about the download speed. > >> - Information abut their local connectivity >> - mtr --report / traceroute output >> - tests from other available hosts OK, that's one out of three. How about the other two? > 15 gayrettepe-t3-1-gayrettepe-t2-1.turktelekom.com.tr (212.156.118.29) > 167.867 ms 167.870 ms 167.862 ms > 16 88.255.240.110 (88.255.240.110) 167.515 ms 168.172 ms 165.829 ms > 17 ns1.gunduz.org (77.79.103.58) 171.574 ms !X * * Output from a smarter traceroute client like "mtr" would be helpful. See below for usage. "mtr" is available for most non-braindead unixes, and is pre-installed on many modern Linux variants. > Are there any good mirrors? Apparently, there is something slow in the > force. Looks fine from here, on iiNet Western Australian ADSL2+ via local 802.11g . That latency is about what I expect for traffic from Western Australia to Turkey via Sydney and the USA. I see similar results from other hosts. Performance when accessing the server is fine. This sample was taken Sat Jan 15 2011, 21:35:55 +0800 time. > [craig@ayaki ~]$ mtr --report-wide --report 77.79.103.58 > HOST: ayaki Loss% Snt Last Avg Best Wrst StDev > 1.|-- bob.iad 0.0% 10 1.9 1.9 1.2 3.7 0.7 > 2.|-- nexthop.wa.iinet.net.au 0.0% 10 16.7 18.6 16.7 28.8 3.7 > 3.|-- te7-2.per-qv1-bdr1.iinet.net.au 0.0% 10 17.7 17.8 17.1 18.6 0.4 > 4.|-- te3-0-0.syd-ult-core1.iinet.net.au 0.0% 10 72.9 72.1 71.4 72.9 0.6 > 5.|-- Bundle-Ether12.chw48.Sydney.telstra.net 0.0% 10 69.3 69.3 68.5 70.3 0.7 > 6.|-- Bundle-Ether6.chw-core2.Sydney.telstra.net 0.0% 10 73.2 73.7 73.1 76.1 0.9 > 7.|-- Bundle-Ether1.oxf-gw2.Sydney.telstra.net 0.0% 10 74.5 75.1 72.6 81.9 3.3 > 8.|-- 203.50.13.102 0.0% 10 70.1 70.5 69.4 72.0 0.8 > 9.|-- i-10-0-0.syd-core03.bi.reach.com 0.0% 10 75.9 75.8 75.0 76.5 0.5 > 10.|-- i-0-3-0-0.1wlt-core01.bx.reach.com 0.0% 10 224.6 223.2 222.5 224.6 0.6 > 11.|-- i-3-4.eqla01.bi.reach.com 0.0% 10 222.2 222.2 221.5 223.4 0.6 > 12.|-- gblx-peer.eqla01.pr.reach.com 0.0% 10 248.0 247.8 246.9 248.4 0.5 > 13.|-- 204.245.38.154 20.0% 10 638.2 520.0 465.1 638.2 71.4 > 14.|-- static.turktelekom.com.tr 10.0% 10 475.1 475.1 471.9 479.8 2.1 > 15.|-- gayrettepe-t3-1-gayrettepe-t2-1.turktelekom.com.tr 10.0% 10 476.2 475.3 472.0 476.8 1.8 > 16.|-- 88.255.240.110 10.0% 10 481.9 490.0 480.6 528.8 15.0 > 17.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 > 18.|-- ns1.gunduz.org 20.0% 10 483.5 482.3 476.7 485.0 2.7 -- Craig Ringer
On 01/15/2011 12:54 AM, Mladen Gogala wrote:
> Craig Ringer wrote:
>> On 01/12/2011 10:16 PM, Guillaume Cottenceau wrote:
>>
>>> What's your point and in what is it related to that ML?
>>
>> Given the package names, I suspect this is a poorly-expressed
>> complaint about the performance of downloads from the pgdg/psqlrpms
>> site. If that was the original poster's intent, they would've been
>> better served with a post that included some minimal details like:
> Yes, it was a complaint about the download speed.
OK, I'm seeing issues too now. It's transient and intermittent - sigh.
The two swear words of IT.
(3/7): postgresql90-9.0.2-2PGDG.f14.x86_64.rpm
| 865 kB 02:04
http://yum.pgrpms.org/9.0/fedora/fedora-14-x86_64/postgresql90-contrib-9.0.2-2PGDG.f14.x86_64.rpm:
[Errno 14] PYCURL ERROR 6 - ""
Trying other mirror.
http://yum.pgrpms.org/9.0/fedora/fedora-14-x86_64/postgresql90-libs-9.0.2-2PGDG.f14.x86_64.rpm:
[Errno 14] PYCURL ERROR 6 - ""
Trying other mirror.
A later try worked. Unfortunately I don't have a timestamp for the
failed attempt, but it was some time yesterday. mtr output and
performance of downloads are presently fine, and I don't have any data
for the problematic period.
--
Craig Ringer
On Wed, 2011-01-12 at 08:49 -0500, Mladen Gogala wrote: <snip> > 7 kilobytes per second??? That brings back the times of the good, old > 9600 USR modems and floppy disks. The machine is serving 40-50 Mbit/sec, and 90% of its traffic is for pgrpms.org. I'm hosting the server in Turkey, and it is my own dedicated machine -- but eventually it will be moved to a machine under postgresql.org infrastructure soon, so it will be faster, I believe. Sorry for the current setup -- it is the only machine that I can host RPMs safely. We are also *considering* to use FTP mirrors as RPM mirrors, too, but I won't promise that now. Please keep looking at http://yum.pgrpms.org for updates. Regards, -- Devrim GÜNDÜZ PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer PostgreSQL RPM Repository: http://yum.pgrpms.org Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz
Attachment
2011/1/18 Devrim GÜNDÜZ <devrim@gunduz.org>: > On Wed, 2011-01-12 at 08:49 -0500, Mladen Gogala wrote: > > <snip> >> 7 kilobytes per second??? That brings back the times of the good, old >> 9600 USR modems and floppy disks. > > The machine is serving 40-50 Mbit/sec, and 90% of its traffic is for > pgrpms.org. I'm hosting the server in Turkey, and it is my own dedicated > machine -- but eventually it will be moved to a machine under > postgresql.org infrastructure soon, so it will be faster, I believe. > Sorry for the current setup -- it is the only machine that I can host > RPMs safely. FYI, we've just had more hardware converted to the new infrastructure platform (literally last night), so hopefully we can provision this machine soon. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company