Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Comcast: Simulating shitty network connections so you can build better systems

github.com

Post reply on HN
Print view View original

61–70 of 87 posts

Re: Comcast: Simulating shitty network connections so you can build better systems

#61

Post by Florin_Andrei »

lucb1e wrote: post #21
blueskin_ wrote: post #12

On linux, tc can do similar things, such as dropping a percentage of packets or adding random delays. http://linux.die.net/man/8/tc

As said in the readme: > you can use tc which supports some additional options. $ tc qdisc add dev eth0 root netem delay 50ms 20ms distribution normal $ tc qdisc change dev eth0 root netem reorder 0.02 duplicate 0.05 corrupt 0.01 > To reset: $ tc qdisc del dev eth0 root netem

Yeah, I used to do stuff like this with tc directly back in the day, but I could never remember the options. This wrapper seems to make it a bit more obvious what goes where.

Re: Comcast: Simulating shitty network connections so you can build better systems

#63

Post by e40 »

phil21 wrote: post #58
e40 wrote: post #40

Earlier quoted context omitted.

Just yesterday I noticed my bill had gone up to $147. I called and did the yearly "I'll cancel if you don't give me a discount" nonsense. An hour out of my day. Btw, they had raised the price of my 5 static IPs to $24.95 (from $9.95). I have to lease their modem ($12.95) because of the static IPs. I did research and found out that my registrar (namecheap.com) has free dynamic dns, so I'm going to switch to that and g…

> I have to lease their modem ($12.95) because of the static IPs. This isn't actually true, assuming you are on the consumer side of the fence. No experience on a business line though. Source: Has extra IPs on his owned modem, after fighting with them for a couple weeks.

It is true, what I said. I have Business Internet and they will not allow activation of a non-Comcast-owned modem when you have static IPs. I know, I tried to do it twice.

Re: Comcast: Simulating shitty network connections so you can build better systems

#64

Post by phil21 »

e40 wrote: post #63
phil21 wrote: post #58

Earlier quoted context omitted.

> I have to lease their modem ($12.95) because of the static IPs. This isn't actually true, assuming you are on the consumer side of the fence. No experience on a business line though. Source: Has extra IPs on his owned modem, after fighting with them for a couple weeks.

It is true, what I said. I have Business Internet and they will not allow activation of a non-Comcast-owned modem when you have static IPs. I know, I tried to do it twice .

Ah yeah, business side I have no experience with. Just wanted to make sure anyone buying on the consumer side knows this, as they tried to pull the same crap with me when it was not true.

Re: Comcast: Simulating shitty network connections so you can build better systems

#65

Post by YuriNiyazov »

jvehent wrote: post #57

I don't need this, I have comcast. $ sudo ping -i 0.02 8.8.8.8 [...] 64 bytes from 8.8.8.8: icmp_seq=578 ttl=53 time=15.5 ms ^C --- 8.8.8.8 ping statistics --- 579 packets transmitted, 364 received, 37% packet loss, time 13854ms rtt min/avg/max/mdev = 15.009/19.308/50.884/6.152 ms, pipe 2

It's so weird to hear so much complaining about Comcast here. My stats with that same command:

     --- 8.8.8.8 ping statistics ---
     615 packets transmitted, 612 packets received, 0.5% packet loss
     round-trip min/avg/max/stddev = 21.332/35.875/95.576/11.248 ms
I have never seen it be anything different.

Re: Comcast: Simulating shitty network connections so you can build better systems

#66

Post by sarciszewski »

YuriNiyazov wrote: post #65
jvehent wrote: post #57

I don't need this, I have comcast. $ sudo ping -i 0.02 8.8.8.8 [...] 64 bytes from 8.8.8.8: icmp_seq=578 ttl=53 time=15.5 ms ^C --- 8.8.8.8 ping statistics --- 579 packets transmitted, 364 received, 37% packet loss, time 13854ms rtt min/avg/max/mdev = 15.009/19.308/50.884/6.152 ms, pipe 2

It's so weird to hear so much complaining about Comcast here. My stats with that same command: --- 8.8.8.8 ping statistics --- 615 packets transmitted, 612 packets received, 0.5% packet loss round-trip min/avg/max/stddev = 21.332/35.875/95.576/11.248 ms I have never seen it be anything different.

> I have never seen it be anything different.

If you parse this statement literally, it has amusing consequences.

Re: Comcast: Simulating shitty network connections so you can build better systems

#67

Post by scott_karana »

mpu wrote: post #38

Written in Go for nothing, you might as well hack a cheap shell script.

Who cares? It also could have been written in Perl, csh, C, APL, Pascal, or Fortran, and it would work exactly the same.

Can we stop shitting on cool things just because the technology being used is "trendy", or you're sick of hearing about it?

Re: Comcast: Simulating shitty network connections so you can build better systems

#69

Post by e40 »

phil21 wrote: post #64
e40 wrote: post #63

Earlier quoted context omitted.

It is true, what I said. I have Business Internet and they will not allow activation of a non-Comcast-owned modem when you have static IPs. I know, I tried to do it twice .

Ah yeah, business side I have no experience with. Just wanted to make sure anyone buying on the consumer side knows this, as they tried to pull the same crap with me when it was not true.

You can't get static IPs on the residential side, btw.

Re: Comcast: Simulating shitty network connections so you can build better systems

#70

Post by exelius »

api wrote: post #55
ot wrote: post #53

Earlier quoted context omitted.

IIRC they said that it's because of the shift to mobile. You can't really do P2P when the majority of your clients sit on phones. EDIT: [I can't reply to the comment below, so I'll add here] It's most likely not a technological problem, but rather than data usage is limited on mobile and you don't want your user to pay for traffic they didn't use.

I keep hearing a categorical "you can't do P2P on mobile." I intend to fling myself at this problem like a drunk seagull soon, so I'll blog on it. I think it's possible, but with a number of special considerations around wakeup-quantization and general power management, some protocol augmentation, and a high tolerance for nodes appearing and disappearing. Primer concept: http://en.wikipedia.org/wiki/Interrupt_coalesc…

The problem isn't power (well it is; but that can be overcome), it's spectrum and pricing.

Pricing: Most people in the US are charged for the data they use on their mobile devices, and thus would not want P2P used on their phone because it costs them money.

Spectrum: P2P is not a very efficient distribution model in a world where most clients are on asynchronous connections. Asynchronous connections exist because transmission spectrum is limited, so to maximize spectrum usage, telcos allocate more spectrum for downstream transmissions than upstream. But if everyone's phone is chattering all the time with P2P traffic, you're going to saturate the spectrum and reduce overall data speeds. This is why mobile is still charged on a usage basis: it discourages overly chatty applications.

Post reply on HN