IRRd-Discuss
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Historical
Re: radb.db.gz
- From: Jens-S. Voeckler
- Date: Thu Oct 07 09:28:49 1999
On Mon, 20 Sep 1999, Gerald Andrew Winters wrote:
]I am sorry to hear about your problems. This is the first time
]we have heard about something like this. To assist you I have
]increased the export frequency to 75 minutes (up from 60 minutes).
]Hopefully this will be enough time. Obviously there is a trade
]off here. For people who do not have slow-link problems they would
]rather have the refresh interval be small. So I do not want to
]increase the interval any further than I have to. Let me know
]how the longer interval works out for you.
I am sorry to report back to you so late, but I was on vacation. A few
times in the meantime I was able to cat a new version, and I will watch
out for my mirroring the next week. During my absence, a few times the
transfer was aborted prematurely, but it seemed to be better.
]I did a quick check. I work from home and have a modem for
]my connectivity which gives me download speeds of around
]2k/second. radb.db.gz is ~2MB which loaded onto my machine
]in 910 seconds or about 15 minutes. I consider 2k/second to
]be pretty slow, but obviously you are experiencing much slower
]download speeds. From the data you have supplied I come up
]with 2MB/3600 seconds = 0.555k/second. This is very, very slow.
]Are you working from a known slow link or is this typical (at
]least with us) speeds you get from North America?
No, it is just you that I am so slow in reaching. Even though our local
whois mirror only uses 10 Mbps ethernet, the next switch goes to the 100
Mbps, the external link is 32 Mbps up to the transatlantic link of 2x45 or
more Mbps. Admittedly, the link is rather busy during (CET) daytime, but
my usual mirror takes place during late evening your time. I guess that
the slow down is somewhere along the way:
2 BWINgate.rrzn.uni-hannover.de (130.75.1.253) * * 15.2 ms
3 Uni-Hannover1.WiN-IP.DFN.DE (188.1.4.5) 4.34 ms 2.65 ms 2.62 ms
4 ZR-Hannover1.WiN-IP.DFN.DE (188.1.144.153) 3.19 ms 3.32 ms 3.11 ms
5 IR-New-York1.WiN-IP.DFN.DE (188.1.144.86) 266 ms 294 ms 280 ms
6 IR-Perryman1.WiN-IP.DFN.DE (188.1.144.198) 268 ms * 270 ms
7 bordercore3-hssi0-0-0.Washington.cw.net (166.48.41.249) 274 ms * 273 ms
8 corerouter2.NorthRoyalton.cw.net (204.70.9.137) 289 ms 290 ms 288 ms
9 bordercore2.NorthRoyalton.cw.net (166.48.224.1) 286 ms * 287 ms
10 merit.NorthRoyalton.cw.net (166.48.225.250) 296 ms 302 ms 298 ms
11 fe0-0-0.michnet10.mich.net (198.108.23.155) 304 ms * *
12 nic.merit.edu (198.108.1.48) 298 ms * 299 ms
If you want to look at the reverse route, use "whois.rvs.uni-hannover.de".
Routing may be asymmetrical, as there are three transatlantik links to
MCI.
]So even from my modem to Europe I can get speeds 4 times faster than
]you. This makes me wonder what is slowing things up for you and I hope
]you can give me a little more information.
Hmm. Trying to ftp things during daytime (with the "hash" option")... Even
just sending the "bin" command takes long enough to let me fetch another
mug of tee from the cafeteria... Judging by the hashes printed by ftp, the
data is coming in bursts with *long* pauses in between. It is an AIX 4.3
system trying to receive the data, though plans are to move it onto our
Sparc-10 and eliminate the (last) AIX system. There are strange things
happening, if tcpdump is to be believed (I have to fgrep instead of using
a "host" config for reasons beyond me):
raven:/ # tcpdump | fgrep merit.edu
tcpdump: listening on en0
14:04:09.326 raven.rvs.uni-hannover.de.2609 > vif03.nic.merit.edu.ftp: P 1848867161:1848867186(25) ack 1986569302 win 16384
14:04:09.700 vif03.nic.merit.edu.ftp > raven.rvs.uni-hannover.de.2609: P 1:31(30) ack 25 win 9216 (DF) [tos 0x10]
14:04:09.701 raven.rvs.uni-hannover.de.2609 > vif03.nic.merit.edu.ftp: P 25:35(10) ack 31 win 16384
14:04:10.118 vif03.nic.merit.edu.ftp > raven.rvs.uni-hannover.de.2609: P 31:51(20) ack 35 win 9216 (DF) [tos 0x10]
14:04:10.118 raven.rvs.uni-hannover.de.2609 > vif03.nic.merit.edu.ftp: P 35:41(6) ack 51 win 16384
14:04:11.920 raven.rvs.uni-hannover.de.2609 > vif03.nic.merit.edu.ftp: P 35:41(6) ack 51 win 16384
14:04:13.960 raven.rvs.uni-hannover.de.2609 > vif03.nic.merit.edu.ftp: P 35:41(6) ack 51 win 16384
14:04:18.303 raven.rvs.uni-hannover.de.2609 > vif03.nic.merit.edu.ftp: P 35:41(6) ack 51 win 16384
14:04:41.709 vif03.nic.merit.edu.ftp-data > raven.rvs.uni-hannover.de.2620: FP 2102230948:2102231268(320) ack 1853162562 win 9216 (DF) [tos 0x8]
14:04:41.709 raven.rvs.uni-hannover.de.2620 > vif03.nic.merit.edu.ftp-data: . ack 321 win 16064
14:04:41.714 raven.rvs.uni-hannover.de.2620 > vif03.nic.merit.edu.ftp-data: F 1:1(0) ack 321 win 16384
14:04:41.715 raven.rvs.uni-hannover.de.2609 > vif03.nic.merit.edu.ftp: P 41:49(8) ack 130 win 16384
14:04:42.521 vif03.nic.merit.edu.ftp-data > raven.rvs.uni-hannover.de.2620: . ack 2 win 9216 (DF) [tos 0x8]
14:04:45.119 vif03.nic.merit.edu.ftp > raven.rvs.uni-hannover.de.2609: P 130:150(20) ack 49 win 9216 (DF) [tos 0x10]
14:04:45.316 raven.rvs.uni-hannover.de.2609 > vif03.nic.merit.edu.ftp: . ack 150 win 16384
Broken pipe
]> what is going on with the ftp.ra.net server? I am trying repeatedly to get
]> a copy of /routing.arbiter/radb/dbase/radb.db.gz, but before I am able to
]> download the complete file, it is being replaced with a new version, thus
]> voiding my download. Since this long-distance download takes longer than
]> an hour, the hourly update of radb.db.gz will never let me catch any
]> version (a two-hourly update might let me catch a copy).
Le deagh dhùrachd,
Dipl.-Ing. Jens-S. Vöckler (voeckler@rvs.uni-hannover.de)
Institute for Computer Networks and Distributed Systems
University of Hanover, Germany; +49 511 762 4726
|