Status
Not open for further replies.

TheRoDent

Expert Member
Joined
Aug 6, 2003
Messages
3,397
So when can I expect my Frogofoot international issue to be solved. Its now been nearly 9 months...

Ticket: COOL-20180711-122832
As soon as my network probes arrive I'll ship you a device so that we can diagnose your line. Your ticket has gone to and fro with Frogfoot with the usual "everything looks alright".
 

_kabal_

Expert Member
Joined
Oct 24, 2005
Messages
2,674
@TheRoDent could you please action your team to process Ticket: #COOL-20190227-225748 so that I can get online.

OpenServe have installed the new CPE and provide the B-number, contained in the ticket
 

MDE

Expert Member
Joined
May 18, 2009
Messages
1,666
@TheRoDent are there any limitations on the proxy server. Was being a bit silly earlier and figured I could just use a nat rule and forward the devices to the web-proxy on my mikrotik.
 

Zodiak

Senior Member
Joined
Sep 2, 2009
Messages
547
Every FNO has their procedures and systems for logging issues and we follow those. I cannot just "escalate" a single consumer line, we have to follow their process.

There is no general Evotel issue that we are aware of so they have to do their troubleshooting and investigations.

I realise you pay us not Evotel, but there isn't a magical "something I can do".
Dear Cool Ideas, I've been dealing with Oliver in Evotel (yes I took it upon myself to speak to Evotel as you're not interested in helping). He has been very helpful and we've tried everything. He confirms that the connection is intact and that the issue is likely with Cool Ideas and not Evotel. Therefore, could you guys actually do something and assist your customer rather than push the blame on Evotel?
 

TheRoDent

Expert Member
Joined
Aug 6, 2003
Messages
3,397
@TheRoDent are there any limitations on the proxy server. Was being a bit silly earlier and figured I could just use a nat rule and forward the devices to the web-proxy on my mikrotik.
Hi, there's no particular limitations but something like a dst-nat for port 80 on your mikrotik would probably only work for HTTP.

It will do SSL, but that requires the client device to use the "CONNECT" verb and to understand to use a proxy server for SSL connections, so a plain nat won't work for SSL.

Twitch and the like use SSL for the streams these days.
 

willsotaku

Well-Known Member
Joined
Mar 3, 2015
Messages
384
Will look into that, but it shouldn't really be an issue unless your line has packet loss during peak periods.
From iperf i get around 2.5%-3% loss during peak time i was told this is acceptable but it makes twitch unusable around 4pm-7pm on the MFN Network but CPT Side proxy is chugging along @ 1080p Source without a hitch even if line has background traffic. could normally not do that this time of day
 

TheRoDent

Expert Member
Joined
Aug 6, 2003
Messages
3,397
Dear Cool Ideas, I've been dealing with Oliver in Evotel (yes I took it upon myself to speak to Evotel as you're not interested in helping). He has been very helpful and we've tried everything. He confirms that the connection is intact and that the issue is likely with Cool Ideas and not Evotel. Therefore, could you guys actually do something and assist your customer rather than push the blame on Evotel?
I have from our side confirmed that your PPPoE connection does dial up, and that I am able to ping your device, however throughput, with a flood ping was dismal.

Evotel still haven't replied to the ticket we logged.

I will ask one of our team leaders to get in contact with you, but from a CISP perspective a throughput issue would indicate a lossy line.
 

TheRoDent

Expert Member
Joined
Aug 6, 2003
Messages
3,397
From iperf i get around 2.5%-3% loss during peak time i was told this is acceptable but it makes twitch unusable around 4pm-7pm on the MFN Network but CPT Side proxy is chugging along @ 1080p Source without a hitch even if line has background traffic. could normally not do that this time of day
That kinda loss is not acceptable and will mess with a TCP connection. The proxy is helping due to it's lower latency retransmission when there is packet loss, which is why your twitch is better.
 

willsotaku

Well-Known Member
Joined
Mar 3, 2015
Messages
384
That kinda loss is not acceptable and will mess with a TCP connection. The proxy is helping due to it's lower latency retransmission when there is packet loss, which is why your twitch is better.
Did an Iperf3 just now with idle line seems like closer to 4% loss if i am reading it correctly this is on a 200/200MBps line with a RB3011Ui-ASM

C:\>iperf3 --verbose --port 17001 -c queen.cisp.co.za --bandwidth 150M -l 1400 --omit 2 -R -u
iperf 3.1.3
CYGWIN_NT-10.0 Rizonx 2.5.1(0.297/5/3) 2016-04-21 22:14 x86_64
Time: Wed, 27 Feb 2019 13:59:37 GMT
Connecting to host queen.cisp.co.za, port 17001
Reverse mode, remote host queen.cisp.co.za is sending
Cookie: Rizonx.1551275977.427974.488a7705666
[ 4] local 192.168.9.21 port 59213 connected to 62.233.65.195 port 17001
Starting Test: protocol: UDP, 1 streams, 1400 byte blocks, omitting 2 seconds, 10 second test
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-1.00 sec 17.2 MBytes 144 Mbits/sec 0.082 ms 1072/13920 (7.7%) (omitted)
[ 4] 1.00-2.00 sec 16.9 MBytes 142 Mbits/sec 0.054 ms 750/13393 (5.6%) (omitted)
[ 4] 0.00-1.00 sec 16.8 MBytes 141 Mbits/sec 0.051 ms 763/13379 (5.7%)
[ 4] 1.00-2.00 sec 17.2 MBytes 145 Mbits/sec 0.082 ms 508/13420 (3.8%)
[ 4] 2.00-3.00 sec 17.1 MBytes 143 Mbits/sec 0.080 ms 558/13361 (4.2%)
[ 4] 3.00-4.00 sec 17.1 MBytes 143 Mbits/sec 0.083 ms 574/13384 (4.3%)
[ 4] 4.00-5.00 sec 17.2 MBytes 144 Mbits/sec 0.119 ms 551/13407 (4.1%)
[ 4] 5.00-6.00 sec 17.1 MBytes 144 Mbits/sec 0.104 ms 554/13393 (4.1%)
[ 4] 6.00-7.00 sec 17.1 MBytes 144 Mbits/sec 0.119 ms 544/13382 (4.1%)
[ 4] 7.00-8.00 sec 17.1 MBytes 144 Mbits/sec 0.049 ms 614/13426 (4.6%)
[ 4] 8.00-9.00 sec 17.4 MBytes 146 Mbits/sec 0.069 ms 355/13397 (2.6%)
[ 4] 9.00-10.00 sec 17.5 MBytes 147 Mbits/sec 0.058 ms 236/13380 (1.8%)
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-10.00 sec 183 MBytes 153 Mbits/sec 0.076 ms 5342/136370 (3.9%)
[ 4] Sent 136370 datagrams
CPU Utilization: local/receiver 38.4% (5.6%u/32.8%s), remote/sender 4.2% (0.6%u/3.7%s)

iperf Done.
 

MDE

Expert Member
Joined
May 18, 2009
Messages
1,666
Hi, there's no particular limitations but something like a dst-nat for port 80 on your mikrotik would probably only work for HTTP.

It will do SSL, but that requires the client device to use the "CONNECT" verb and to understand to use a proxy server for SSL connections, so a plain nat won't work for SSL.

Twitch and the like use SSL for the streams these days.
Thanks.
 

Zodiak

Senior Member
Joined
Sep 2, 2009
Messages
547
I have from our side confirmed that your PPPoE connection does dial up, and that I am able to ping your device, however throughput, with a flood ping was dismal.

Evotel still haven't replied to the ticket we logged.

I will ask one of our team leaders to get in contact with you, but from a CISP perspective a throughput issue would indicate a lossy line.
That's great, and you guys can't pick up the phone to Evotel? Is that too much effort?
 

Armizael

Well-Known Member
Joined
May 31, 2006
Messages
342
That's great, and you guys can't pick up the phone to Evotel? Is that too much effort?
I get that you're frustrated, but you're literally attacking the person who wants to help you - they've logged the call with Evotel, that's the process given to them to follow from Evotel.
I'm fairly sure they'll just tell CI to log a ticket as per their processes set out for ISPs dealing with them.

Stellar example of why ISPs don't bother with reps on this forum anymore.

Clearly according to you CI dropped the ball here - maybe it's time to find an ISP for you that won't?
 
Status
Not open for further replies.
Top