Screamer WiMax

wow4life said:
I guess WiMax is just not suitable for fps-type gaming .
Click to expand...

Not True. It doesn't matter how many times I point this out, people still ignore it.
WiMax is great, if you implement it properly. What you're seeing, are the results of a bad implementation.
 
I jus got a call from someone at screamer. Very helpful and informative! Would really like to switch to them - neotel is so bad.
 
ushir said:
I jus got a call from someone at screamer. Very helpful and informative! Would really like to switch to them - neotel is so bad.
Click to expand...

I know that the Tech Dir at Screamer has waived the installation costs for ex-Neotel clients to help somewhat with the "bitter pill" of having to pay for their Neotel CPE on cancellation.

Bring this up with the Screamer consultants if they dont;)
 
daffy said:
Not True. It doesn't matter how many times I point this out, people still ignore it.
WiMax is great, if you implement it properly. What you're seeing, are the results of a bad implementation.
Click to expand...

Are you aware of WiMax installations that have zero packet loss?
 
wow4life said:
Are you aware of WiMax installations that have zero packet loss?
Click to expand...

Hi there Wowforlife

Our standard is that there is zero packet loss. I know that the technicians were going to check the polarity on your installation last week but apparently were told that everything was OK and so did not make the call:confused:

I will make sure the visit is rescheduled.
 
ushir said:
I jus got a call from someone at screamer. Very helpful and informative! Would really like to switch to them - neotel is so bad.
Click to expand...

Dude go for it. I had them out here and all in all the service was great. I just didn't have strong enough signal sadly.

Give Neotel the shaft.
 
howzit said:
Hi there Wowforlife

Our standard is that there is zero packet loss. I know that the technicians were going to check the polarity on your installation last week but apparently were told that everything was OK and so did not make the call:confused:

I will make sure the visit is rescheduled.
Click to expand...

Thanks the guys cam today and switched polarity - this resulted in an improvement from approx 1% packet loss to nearly 0%. For example since they left my premises I had 33 packets lost in 3728. According to the team this is normal and to be expected.

There are other problems from the tower that they are following up (which result in disconnects).
 
hmm sofar today have had 2 disconnects right after browsing the web.
had to reboot router. :(
Dissconnects were @ 13:17 and round about 13:30 this afternoon

having rebooted router sofar seems stable.

Pinging 172.17.0.10 with 32 bytes of data:
Reply from 172.17.0.10: bytes=32 time=180ms TTL=60
Reply from 172.17.0.10: bytes=32 time=73ms TTL=60
Reply from 172.17.0.10: bytes=32 time=65ms TTL=60
Reply from 172.17.0.10: bytes=32 time=70ms TTL=60
Reply from 172.17.0.10: bytes=32 time=66ms TTL=60
Reply from 172.17.0.10: bytes=32 time=75ms TTL=60
Reply from 172.17.0.10: bytes=32 time=73ms TTL=60
Reply from 172.17.0.10: bytes=32 time=64ms TTL=60
Reply from 172.17.0.10: bytes=32 time=70ms TTL=60
Reply from 172.17.0.10: bytes=32 time=63ms TTL=60

Ping statistics for 172.17.0.10:
Packets: Sent = 10, Received = 10, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 63ms, Maximum = 180ms, Average = 79ms
 
Just ran this - definite improvement in packet loss (esp late at night). Still seeing some disconnects though but getting better ....

Ping statistics for 172.17.0.10:
Packets: Sent = 365, Received = 363, Lost = 2 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 33ms, Maximum = 89ms, Average = 40ms
 
Been monitoring my connection as the packet loss is consistently at 0.1% so a nice improvement.

The problems that now occur are latency spikes. This is evidenced by:
* Normal latency: 40-50ms -> High latency: 150ms-500ms -> Packet Loss (not always) -> High latency -> Normal latency

(monitored to 172.17.0.10)
 
Perhaps the problems is with the downlink pipe being flooded .... is there a tool that monitors how much data I am currently receiving? I did a quick search on the net but most tools seem to focus on managing downloads (for capped accounts).

Would be great to monitor this vs when I get the high latency/disconnects.
 
Thanks all, will give them a bash.

I guess I will have to configure my connection directly to the IDU to get an accurate view (i.e. not through the router) to elimate traffic from other machines. Unless one of these tools monitor what traffic other machines are generating.

When I ran tests last night I never spiked and was consistently in the range of 0.1 to 0.4mbps for my own NIC.
 
anyone here got theier screamer hooked up to an ISA server ?

i got one sitting @ home and was thinking of setting up screamer to my isa server...
 
Thanks - I have been running a tool called Bandwidth Monitor by Rokario and it doesn't seem to indicate a problem. With nobody else using my connection I had a disconnect when by downlink was around 0.6mbps.

Will try the tool you recommended above.
 
Packet loss is still quite low now, which is great. Caught the severe error again at 23:45 tonight:

Reply from 172.17.0.10: bytes=32 time=38ms TTL=60
Reply from 172.17.0.10: bytes=32 time=42ms TTL=60
Reply from 172.17.0.10: bytes=32 time=40ms TTL=60
Reply from 172.17.0.10: bytes=32 time=39ms TTL=60
Reply from 172.17.0.10: bytes=32 time=42ms TTL=60
Reply from 172.17.0.10: bytes=32 time=40ms TTL=60
Reply from 192.168.2.1: Destination net unreachable.
Reply from 192.168.2.1: Destination net unreachable.
Reply from 192.168.2.1: Destination net unreachable.
Reply from 192.168.2.1: Destination net unreachable.
Reply from 192.168.2.1: Destination net unreachable.
Request timed out.
Reply from 172.17.0.10: bytes=32 time=36ms TTL=60
Reply from 172.17.0.10: bytes=32 time=44ms TTL=60
Reply from 172.17.0.10: bytes=32 time=34ms TTL=60
Reply from 172.17.0.10: bytes=32 time=37ms TTL=60
Reply from 172.17.0.10: bytes=32 time=36ms TTL=60
 
wow4life said:
Packet loss is still quite low now, which is great. Caught the severe error again at 23:45 tonight:

Reply from 172.17.0.10: bytes=32 time=38ms TTL=60
Reply from 172.17.0.10: bytes=32 time=42ms TTL=60
Reply from 172.17.0.10: bytes=32 time=40ms TTL=60
Reply from 172.17.0.10: bytes=32 time=39ms TTL=60
Reply from 172.17.0.10: bytes=32 time=42ms TTL=60
Reply from 172.17.0.10: bytes=32 time=40ms TTL=60
Reply from 192.168.2.1: Destination net unreachable.
Reply from 192.168.2.1: Destination net unreachable.
Reply from 192.168.2.1: Destination net unreachable.
Reply from 192.168.2.1: Destination net unreachable.
Reply from 192.168.2.1: Destination net unreachable.
Request timed out.
Reply from 172.17.0.10: bytes=32 time=36ms TTL=60
Reply from 172.17.0.10: bytes=32 time=44ms TTL=60
Reply from 172.17.0.10: bytes=32 time=34ms TTL=60
Reply from 172.17.0.10: bytes=32 time=37ms TTL=60
Reply from 172.17.0.10: bytes=32 time=36ms TTL=60
Click to expand...

Yep, as explained in my pm to you our bandwidth monitor disconnects all connections momentarily at about midnight so that it can establish a clear distinction between one days usage and the next.
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X