Feedback for IDM

Hey,
Is the VR900 better than the Asus? Does it allow bandwidth control? Like giving each Device x mbps bandwidth?

The VR900 has a better chipset for modem than the Asus but i don' t have it so someone else should shed some light.

The Asus have bandwidth control and it works just fine (but i am using it as router only)

Pinging 8.8.8.8 with 32 bytes of data:
Reply from 8.8.8.8: bytes=32 time=292ms TTL=51
Reply from 8.8.8.8: bytes=32 time=292ms TTL=51
Reply from 8.8.8.8: bytes=32 time=290ms TTL=51
Reply from 8.8.8.8: bytes=32 time=395ms TTL=51
Reply from 8.8.8.8: bytes=32 time=308ms TTL=51
Reply from 8.8.8.8: bytes=32 time=363ms TTL=51
Reply from 8.8.8.8: bytes=32 time=285ms TTL=51
Reply from 8.8.8.8: bytes=32 time=330ms TTL=51
Reply from 8.8.8.8: bytes=32 time=294ms TTL=51
Reply from 8.8.8.8: bytes=32 time=403ms TTL=51
Reply from 8.8.8.8: bytes=32 time=306ms TTL=51

Ping statistics for 8.8.8.8:
Packets: Sent = 11, Received = 11, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 285ms, Maximum = 403ms, Average = 323ms

Good luck gaming on that ping.

Is anyone else getting those figures?

Time of test 12:08 AM

alcolopa wrotePinging 8.8.8.8 with 32 bytes of data:
Reply from 8.8.8.8: bytes=32 time=292ms TTL=51
Reply from 8.8.8.8: bytes=32 time=292ms TTL=51
Reply from 8.8.8.8: bytes=32 time=290ms TTL=51
Reply from 8.8.8.8: bytes=32 time=395ms TTL=51
Reply from 8.8.8.8: bytes=32 time=308ms TTL=51
Reply from 8.8.8.8: bytes=32 time=363ms TTL=51
Reply from 8.8.8.8: bytes=32 time=285ms TTL=51
Reply from 8.8.8.8: bytes=32 time=330ms TTL=51
Reply from 8.8.8.8: bytes=32 time=294ms TTL=51
Reply from 8.8.8.8: bytes=32 time=403ms TTL=51
Reply from 8.8.8.8: bytes=32 time=306ms TTL=51

Ping statistics for 8.8.8.8:
Packets: Sent = 11, Received = 11, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 285ms, Maximum = 403ms, Average = 323ms

Good luck gaming on that ping.

Is anyone else getting those figures?

Time of test 12:08 AM

Pinging 8.8.8.8 with 32 bytes of data:
Reply from 8.8.8.8: bytes=32 time=53ms TTL=50
Reply from 8.8.8.8: bytes=32 time=153ms TTL=50
Reply from 8.8.8.8: bytes=32 time=55ms TTL=50
Reply from 8.8.8.8: bytes=32 time=50ms TTL=50
Reply from 8.8.8.8: bytes=32 time=46ms TTL=50
Reply from 8.8.8.8: bytes=32 time=55ms TTL=50
Reply from 8.8.8.8: bytes=32 time=54ms TTL=50
Reply from 8.8.8.8: bytes=32 time=58ms TTL=50 Ping statistics for 8.8.8.8:
Packets: Sent = 8, Received = 8, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 46ms, Maximum = 153ms, Average = 65ms

Everything seems okay here, a bit unstable but that's nothing out of the ordinary.

I noticed that variation in ping yesterday on Ogero for the first time. But download speeds seemed stable and consistent on 1200 kb/sec. More people are staying at home now I guess.

It is around 125 ms now (4:30 PM), it was around 80 ms in the morning

Reply from 8.8.8.8: bytes=32 time=106ms TTL=48
Reply from 8.8.8.8: bytes=32 time=155ms TTL=48
Reply from 8.8.8.8: bytes=32 time=183ms TTL=48
Reply from 8.8.8.8: bytes=32 time=109ms TTL=48
Reply from 8.8.8.8: bytes=32 time=135ms TTL=48
Reply from 8.8.8.8: bytes=32 time=111ms TTL=48
Reply from 8.8.8.8: bytes=32 time=116ms TTL=48
Reply from 8.8.8.8: bytes=32 time=106ms TTL=48
Reply from 8.8.8.8: bytes=32 time=105ms TTL=48
Reply from 8.8.8.8: bytes=32 time=111ms TTL=48
Reply from 8.8.8.8: bytes=32 time=106ms TTL=48
Reply from 8.8.8.8: bytes=32 time=111ms TTL=48
Reply from 8.8.8.8: bytes=32 time=108ms TTL=48
Reply from 8.8.8.8: bytes=32 time=117ms TTL=48
Reply from 8.8.8.8: bytes=32 time=106ms TTL=48
Reply from 8.8.8.8: bytes=32 time=161ms TTL=48
Reply from 8.8.8.8: bytes=32 time=134ms TTL=48
Reply from 8.8.8.8: bytes=32 time=104ms TTL=48
Reply from 8.8.8.8: bytes=32 time=109ms TTL=48
Reply from 8.8.8.8: bytes=32 time=135ms TTL=48
Reply from 8.8.8.8: bytes=32 time=138ms TTL=48
Reply from 8.8.8.8: bytes=32 time=139ms TTL=48
Reply from 8.8.8.8: bytes=32 time=147ms TTL=48
Reply from 8.8.8.8: bytes=32 time=119ms TTL=48
Reply from 8.8.8.8: bytes=32 time=148ms TTL=48
Reply from 8.8.8.8: bytes=32 time=112ms TTL=48
Reply from 8.8.8.8: bytes=32 time=107ms TTL=48

Ping statistics for 8.8.8.8:
Packets: Sent = 31, Received = 31, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 104ms, Maximum = 183ms, Average = 123ms

Pinging 8.8.8.8 with 32 bytes of data:
Reply from 8.8.8.8: bytes=32 time=81ms TTL=51
Reply from 8.8.8.8: bytes=32 time=94ms TTL=51
Reply from 8.8.8.8: bytes=32 time=100ms TTL=51
Reply from 8.8.8.8: bytes=32 time=91ms TTL=51
Reply from 8.8.8.8: bytes=32 time=80ms TTL=51
Reply from 8.8.8.8: bytes=32 time=99ms TTL=51
Reply from 8.8.8.8: bytes=32 time=117ms TTL=51
Reply from 8.8.8.8: bytes=32 time=97ms TTL=51
Reply from 8.8.8.8: bytes=32 time=81ms TTL=51
Reply from 8.8.8.8: bytes=32 time=96ms TTL=51
Reply from 8.8.8.8: bytes=32 time=89ms TTL=51
Reply from 8.8.8.8: bytes=32 time=96ms TTL=51
Reply from 8.8.8.8: bytes=32 time=92ms TTL=51
Reply from 8.8.8.8: bytes=32 time=88ms TTL=51
Reply from 8.8.8.8: bytes=32 time=104ms TTL=51
Reply from 8.8.8.8: bytes=32 time=85ms TTL=51
Reply from 8.8.8.8: bytes=32 time=80ms TTL=51
Reply from 8.8.8.8: bytes=32 time=85ms TTL=51
Reply from 8.8.8.8: bytes=32 time=113ms TTL=51
Reply from 8.8.8.8: bytes=32 time=98ms TTL=51
Reply from 8.8.8.8: bytes=32 time=94ms TTL=51
Reply from 8.8.8.8: bytes=32 time=90ms TTL=51
Reply from 8.8.8.8: bytes=32 time=93ms TTL=51
Reply from 8.8.8.8: bytes=32 time=94ms TTL=51
Reply from 8.8.8.8: bytes=32 time=85ms TTL=51

Ping statistics for 8.8.8.8:
Packets: Sent = 25, Received = 25, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 80ms, Maximum = 117ms, Average = 92ms

Everything seems to be fine right now some spikes here and there but it's fine! Syncing on ADSL2

29/03/2020 22:34:42.31

Pinging 192.168.1.254 with 32 bytes of data:
Reply from 192.168.1.254: bytes=32 time<1ms TTL=64
Reply from 192.168.1.254: bytes=32 time<1ms TTL=64
Reply from 192.168.1.254: bytes=32 time<1ms TTL=64
Reply from 192.168.1.254: bytes=32 time<1ms TTL=64
Reply from 192.168.1.254: bytes=32 time<1ms TTL=64
Reply from 192.168.1.254: bytes=32 time<1ms TTL=64
Reply from 192.168.1.254: bytes=32 time<1ms TTL=64
Reply from 192.168.1.254: bytes=32 time<1ms TTL=64
Reply from 192.168.1.254: bytes=32 time<1ms TTL=64
Reply from 192.168.1.254: bytes=32 time<1ms TTL=64
Reply from 192.168.1.254: bytes=32 time<1ms TTL=64
Reply from 192.168.1.254: bytes=32 time<1ms TTL=64
Reply from 192.168.1.254: bytes=32 time<1ms TTL=64
Reply from 192.168.1.254: bytes=32 time<1ms TTL=64
Reply from 192.168.1.254: bytes=32 time<1ms TTL=64
Reply from 192.168.1.254: bytes=32 time<1ms TTL=64
Reply from 192.168.1.254: bytes=32 time<1ms TTL=64
Reply from 192.168.1.254: bytes=32 time<1ms TTL=64
Reply from 192.168.1.254: bytes=32 time<1ms TTL=64
Reply from 192.168.1.254: bytes=32 time<1ms TTL=64

Ping statistics for 192.168.1.254:
Packets: Sent = 20, Received = 20, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms

Pinging 212.36.211.163 with 32 bytes of data:
Reply from 212.36.211.163: bytes=32 time=50ms TTL=62
Reply from 212.36.211.163: bytes=32 time=43ms TTL=62
Reply from 212.36.211.163: bytes=32 time=42ms TTL=62
Reply from 212.36.211.163: bytes=32 time=44ms TTL=62
Request timed out.
Reply from 212.36.211.163: bytes=32 time=41ms TTL=62
Request timed out.
Reply from 212.36.211.163: bytes=32 time=49ms TTL=62
Reply from 212.36.211.163: bytes=32 time=44ms TTL=62
Request timed out.
Reply from 212.36.211.163: bytes=32 time=41ms TTL=62
Reply from 212.36.211.163: bytes=32 time=41ms TTL=62
Reply from 212.36.211.163: bytes=32 time=47ms TTL=62
Reply from 212.36.211.163: bytes=32 time=41ms TTL=62
Reply from 212.36.211.163: bytes=32 time=41ms TTL=62
Reply from 212.36.211.163: bytes=32 time=44ms TTL=62
Reply from 212.36.211.163: bytes=32 time=41ms TTL=62
Reply from 212.36.211.163: bytes=32 time=42ms TTL=62
Reply from 212.36.211.163: bytes=32 time=43ms TTL=62
Reply from 212.36.211.163: bytes=32 time=41ms TTL=62

Ping statistics for 212.36.211.163:
Packets: Sent = 20, Received = 17, Lost = 3 (15% loss),
Approximate round trip times in milli-seconds:
Minimum = 41ms, Maximum = 50ms, Average = 43ms

Tracing route to 212.36.211.163 over a maximum of 30 hops

1 <1 ms <1 ms <1 ms 192.168.1.254
2 42 ms 42 ms 41 ms 172.17.18.1
3 42 ms 51 ms 41 ms 212.36.211.163

Trace complete.

Pinging 8.8.4.4 with 32 bytes of data:
Reply from 8.8.4.4: bytes=32 time=80ms TTL=51
Request timed out.
Reply from 8.8.4.4: bytes=32 time=81ms TTL=51
Reply from 8.8.4.4: bytes=32 time=80ms TTL=51
Reply from 8.8.4.4: bytes=32 time=79ms TTL=51
Reply from 8.8.4.4: bytes=32 time=82ms TTL=51
Request timed out.
Reply from 8.8.4.4: bytes=32 time=79ms TTL=51
Reply from 8.8.4.4: bytes=32 time=79ms TTL=51
Reply from 8.8.4.4: bytes=32 time=79ms TTL=51
Reply from 8.8.4.4: bytes=32 time=79ms TTL=51
Reply from 8.8.4.4: bytes=32 time=79ms TTL=51
Reply from 8.8.4.4: bytes=32 time=79ms TTL=51
Reply from 8.8.4.4: bytes=32 time=79ms TTL=51
Reply from 8.8.4.4: bytes=32 time=85ms TTL=51

Ping statistics for 8.8.4.4:
Packets: Sent = 15, Received = 13, Lost = 2 (13% loss),
Approximate round trip times in milli-seconds:
Minimum = 79ms, Maximum = 85ms, Average = 80ms

Tracing route to 8.8.4.4 over a maximum of 30 hops

1 <1 ms <1 ms <1 ms 192.168.1.254
2 43 ms 42 ms 45 ms 172.17.18.1
3 * * * Request timed out.
4 42 ms 41 ms 41 ms 212.36.211.164
5 45 ms 41 ms 41 ms 212.36.211.201
6 * * 41 ms 172.16.50.1
7 * * * Request timed out.
8 43 ms 43 ms * 172.16.49.1
9 81 ms 92 ms 82 ms 212.73.201.129
10 78 ms 81 ms * 4.69.159.134
11 80 ms 80 ms * 72.14.214.210
12 81 ms 80 ms 80 ms 108.170.252.241
13 80 ms 80 ms 80 ms 72.14.233.67
14 81 ms 79 ms 82 ms 8.8.4.4

Trace complete.


I mean the ms is good now but the packet loss is killing me

Hello everyone, i used to have my IDM connection configured using bridge mode setup, with the technicolor modem (setup bridge mode) connected to tp-link router (setup pppoe). However, the connection stopped working without doing any change to the settings. I called them and they told me to reset the modem to factory setting. The modem still connects to the internet if it is set in pppoe setting and not in bridge mode. Do you think IDM is not allowing bridge mode connections? Would they assist in such a case?

wollyka wroteI used to have the same setup but i has to change it a little when i switched to VDSL because the new modem supplied by IDM doesn't have bridge mode. So now, I let the modem connect using pppoe and i put the router in automatic IP mode. Also i put the router in the DMZ zone in the modem settings.

Thanks for the reply, I have dd-wrt firmware installed on my router, so I set it to Automatic Configuration - DHCP, and it worked with the modem. I don't have a DMZ mode on the modem, I only have a "Assign the public IP address of a connection to a device" option. After adding the router to this option, a popup informs me "to release the current private IP address of the device and then renew the IP address to acquire a public IP address". The connection then drops and no longer works. Any idea on what is happening?

StannisTheMannis wrote

wollyka wroteI used to have the same setup but i has to change it a little when i switched to VDSL because the new modem supplied by IDM doesn't have bridge mode. So now, I let the modem connect using pppoe and i put the router in automatic IP mode. Also i put the router in the DMZ zone in the modem settings.

Thanks for the reply, I have dd-wrt firmware installed on my router, so I set it to Automatic Configuration - DHCP, and it worked with the modem. I don't have a DMZ mode on the modem, I only have a "Assign the public IP address of a connection to a device" option. After adding the router to this option, a popup informs me "to release the current private IP address of the device and then renew the IP address to acquire a public IP address". The connection then drops and no longer works. Any idea on what is happening?

This is the DMZ option, the modem is ancient and must be changed the firmware is usually messed up along with its updates. Anyways to use this feature you should assign the DMZed device a static local IP usually not within the DHCP range.

Meaning if your range is 192.168.1.100-254 then pick 192.168.1.5 for example.

Kareem_nasser is right. You can do it in two ways:
My modem have an ip of 192.168.1.1. I have enabled the DHCP server on the modem but the ranges the DHCP server is giving are in the 192.168.1.2XX range. I have added the mac address of the router in the modem to always give it an IP of 192.168.1.200. so you can add that address to the DMZ zone. The router is on Automatic IP.

Another way:
Disable the DHCP server on the modem, give the router a static IP that is different from the modem IP. eg. modem IP 192.168.1.1, router IP 192.168.1.200. Set the gateway and the DNS servers in the router as the modem IP 192.168.1.1. Then in the modem, add the IP of the router (192.168.1.200) in the DMZ zone.
I also enabled the DHCP server in the router. However, it is giving an different IP range e.g. 192.168.2.XX to the devices connected through WIFI to the router.

My best ping in gaming is 140ms , iam IDM user , Does switching from GDS to ogero solves this problem ?

masrour wroteMy best ping in gaming is 140ms , iam IDM user , Does switching from GDS to ogero solves this problem ?

I don't think it would. I'm on the GDS network and am getting latency in the mid 50ms range in Rainbow Six Siege and around 60-70 in most other games. What game are you playing as even in the worst case 140ms is really bad if it's on a European server. You could ask them to turn off interleaving or switch to G.DMT which I believe doesn't have error correction (and thus lower latency).

Super Official wrote

masrour wroteMy best ping in gaming is 140ms , iam IDM user , Does switching from GDS to ogero solves this problem ?

I don't think it would. I'm on the GDS network and am getting latency in the mid 50ms range in Rainbow Six Siege and around 60-70 in most other games. What game are you playing as even in the worst case 140ms is really bad if it's on a European server. You could ask them to turn off interleaving or switch to G.DMT which I believe doesn't have error correction (and thus lower latency).

R6S is most probably a P2P connection.

kareem_nasser wrote

Super Official wrote

masrour wroteMy best ping in gaming is 140ms , iam IDM user , Does switching from GDS to ogero solves this problem ?

I don't think it would. I'm on the GDS network and am getting latency in the mid 50ms range in Rainbow Six Siege and around 60-70 in most other games. What game are you playing as even in the worst case 140ms is really bad if it's on a European server. You could ask them to turn off interleaving or switch to G.DMT which I believe doesn't have error correction (and thus lower latency).

R6S is most probably a P2P connection.

Siege uses dedicated Microsoft Azure servers in every region. I usually connect to north or west Europe. Both give me the same latency around 55ms.

Iam playing at mobile and ipad ( pubg and COD ), I configured the modem at G.DMT but gets the same ping , my neighbour already in IDM but in ogero central and his ping about 60-70 ms .. we have elevator interference when its on (ping goes to 400-500 ) , but its not a problem since iam overnight player and solving this issue is high expensive (allah bi 3een) , but when its off sometimes ping to europe is high , now at 1 am 230 ms :( , i don't what to do i tried to call support talking 3 and 4 hours without any solution (turning interleaving off is from ogero only as support said ) .. that's why i asked which better GDS or Ogero ?