vodacom3g
Vodacom Representative
kaspaas said:
It's a function of some convoluted routing, being sorted at the moment.
-
Join the MyBroadband community
South Africa’s biggest forum. Discuss, discover, and connect with thousands of members.
-
Question of the Day: Have you ever been to an airshow?
COMPLAINT: Endless DNS errors
- Thread starter aisne
- Start date
It's a function of some convoluted routing, being sorted at the moment.
Nope, this is what I get:biometrics said:
Code:
2.2.210.168.in-addr.arpa. 15829 IN PTR dnscache1.is.co.za.
2.239.14.196.in-addr.arpa. 15773 IN PTR dnscache2.is.co.za.
biometrics
Honorary Master
- Joined
- Aug 7, 2003
- Messages
- 71,856
- Reaction score
- 2,239
Does it make a difference that I'm on the 'internetvpn' APN?
Since I haven't tried the internetvpn apn yet, I cannot say, but if you get different automatically assigned DNS servers then the answer is probably yes...biometrics said:
v3g, just wondering how quickly Vodacom can make their own DNS servers available for 3G/GPRS [data] customers - rather than relying on the upstream IS DNS server(s)?
vodacom3g
Vodacom Representative
Process already started, so hopefully soon.
vodacom3g said:
I was wondering if Vodacom's own internal DNS Server(s) [if any] that would be used by Vodacom employees from the Vodacom intranet, are accessible to data customers, i.e. before breaking-out to Internet Solutions? If so, then data customers could [as a temporary workaround] manually set their machines to use a Vodacom DNS Server as their primary DNS, and IS as secondary...Also, when Vodacom has data customers using Vodacom's own DNS servers, it should save Vodacom some bandwidth costs - since no DNS requests would need to go beyond the Vodacom network...
regardtv
Expert Member
Convoluted technical response to follow:
Since the primary problem of DNS timeouts on high latency connections tend to be the actual packet turnaround times (sometimes >5000ms) there is a rather back-handed way of managing the solution...
Windows will "tend" to pick the primary DNS server for queries repeatedly, if that server has the data cached it tend to be able to deliver it to a windows client without too much of a hitch... If however it has to recurse to find the info windows will fail over to the secondary DNS ... (this is basics but I've included it for completeness & clarity)...
In order to trick Windows we provide 2 actual DNS servers but 4 DNS IP's in auto assignment....
Server1 (IP1) ... DNS1
Server1 (IP2) ... DNS2
Server2 (IP1) ... DNS3
Server2 (IP2) ... DNS4
Doing this will allow the DNS server time to fetch the query and have it cached by the time the windows client fails over and connects to the server again on a seperate IP ...
I've tested this and have had some positive results ...
If the problem also tends to occur on cached local queries one obviously needs to take another look at route delays and server performance ...
...THIS IS NOT RECOMMENDED BUT SEEMS TO WORK...
Since the primary problem of DNS timeouts on high latency connections tend to be the actual packet turnaround times (sometimes >5000ms) there is a rather back-handed way of managing the solution...
Windows will "tend" to pick the primary DNS server for queries repeatedly, if that server has the data cached it tend to be able to deliver it to a windows client without too much of a hitch... If however it has to recurse to find the info windows will fail over to the secondary DNS ... (this is basics but I've included it for completeness & clarity)...
In order to trick Windows we provide 2 actual DNS servers but 4 DNS IP's in auto assignment....
Server1 (IP1) ... DNS1
Server1 (IP2) ... DNS2
Server2 (IP1) ... DNS3
Server2 (IP2) ... DNS4
Doing this will allow the DNS server time to fetch the query and have it cached by the time the windows client fails over and connects to the server again on a seperate IP ...
I've tested this and have had some positive results ...
If the problem also tends to occur on cached local queries one obviously needs to take another look at route delays and server performance ...
...THIS IS NOT RECOMMENDED BUT SEEMS TO WORK...
Routing problems?
One question:
My V3G DNS echo requests (pings!) seem to show that the first request
usually takes more than 3000 msecs, yet subsequent requests get
<300 msec responses!
(I am 'pinging' the DNS server 168.210.2.2 itself, so it does not have to
do ANY resolving, simply respond. Simply open a command prompt, and
type: PING 168.210.2.2 and see!)
From what I know of IP routing, it would appear as if the routers between
me and the DNS server first has to establish a route?
Wait approx 20 secs, and the >3000msec delay is back!
Maybe the routers need larger routing tables?
(This may not be possible without complete replacement
)
One question:
My V3G DNS echo requests (pings!) seem to show that the first request
usually takes more than 3000 msecs, yet subsequent requests get
<300 msec responses!
(I am 'pinging' the DNS server 168.210.2.2 itself, so it does not have to
do ANY resolving, simply respond. Simply open a command prompt, and
type: PING 168.210.2.2 and see!)
From what I know of IP routing, it would appear as if the routers between
me and the DNS server first has to establish a route?
Wait approx 20 secs, and the >3000msec delay is back!
Maybe the routers need larger routing tables?
(This may not be possible without complete replacement
)
Last edited:
vodacom3g
Vodacom Representative
You've actually discovered a characteristic of the UMTS network.
When you've not transmitted any data for a while, your connection is placed in an 'idle' mode so as to better manage available bandwidth for everyone else. When you then transmit a packet again, your connection is 'woken up' and normal service resumes.
The upshot of this is a slightly longer delay on the first packet.
So it's not a routing issue at all but rather the way the network works.
When you've not transmitted any data for a while, your connection is placed in an 'idle' mode so as to better manage available bandwidth for everyone else. When you then transmit a packet again, your connection is 'woken up' and normal service resumes.
The upshot of this is a slightly longer delay on the first packet.
So it's not a routing issue at all but rather the way the network works.
Last edited:
biometrics
Honorary Master
- Joined
- Aug 7, 2003
- Messages
- 71,856
- Reaction score
- 2,239
So does that mean running a continuous ping will deliver better performance: ping -t ... ?
Mmm, maybe I should build that in as a feature of my 3G Dialer software!
Mmm, maybe I should build that in as a feature of my 3G Dialer software!
vodacom3g
Vodacom Representative
In theory; yes. Practically; no, depending on your usage patterns. Remember, it's only the first packet that gets delayed.
Most PC's today generate a constant stream of activity so this will not affect them.
Having a configurable ping (size and delay) in your app will be nice though. Kinda like a Health Check on the connection.
Just remember, your going to pay for the pings, as it's normal data.
Most PC's today generate a constant stream of activity so this will not affect them.
Having a configurable ping (size and delay) in your app will be nice though. Kinda like a Health Check on the connection.
Just remember, your going to pay for the pings, as it's normal data.