The DnD Sanctuary

I've skipped that "Run the poll for:" thing, and decided to make the 3rd test poll with users changing their votes. So use it.

This thread is temporary. Consider it.

Note: testing some smilies in the poll...

The smilies work great(https://dndsanctuary.eu/imagecache.php?image=http%3A%2F%2Fi.imgur.com%2FKyapDYu.png&hash=feb6af59c2ef482fa96049357ff658f5" rel="cached" data-hash="feb6af59c2ef482fa96049357ff658f5" data-warn="External image, click here to view original" data-url="http://i.imgur.com/KyapDYu.png)

ׂ

My Dropbox is still "temporarily banned". That's the second week. Apparently the ban is triggered by leeching 20 gigabytes per day. That's 2 hours of effort to kill another person's account. I wonder who had I pissed off enough for that. Stupid Dropbox.

You'd think they'd put an IP ban on the leecher after one or two GB, not the account being leeched from. O_o

If I go to the overlords' streaming video site to read and post some comments, it starts loading the damn video immediately. If I go to any russian site, I get bombarded with "teasers" slowing my computer to a halt.

I know, right. These days I often find myself preferring Flash over HTML5 because at least Flash is fully blocked from loading until I click to play. I thought they'd promised the ability to better control what exactly happened to HTML5 media regardless of some stupid autoplay attribute.

So far I've only tried from G.Chrome...
Well, still - on the other hand - there's a relief when the limit is up: I can freely listen to almost any of the dowloaded radiostreams I like - without worrying about "gosh! this meter's damn ticking, boo!..";)

What do they drop your speed to?

128 (http://en.wikipedia.org/wiki/Data_rate_units#Kilobit_per_second). It's mobile internet - I have few wires here: except for the power-plug, the other two (and half) are to the speakers and a 2m extender for my GPRS-modem.

128kbps? Well, at least it's better than the 64kbps to which they drop mine. :right:

Yup, and this particular package option I use is closed to choose now.

ׂ

True, at 50Mbit I can download several videos from YouTube at once without noticing a thing. Even if it's a few hundred MB it's already half done by the time I start the second download anyway… But that's kind of the point of dropping you to 10Mbit, of course—so you won't strain the network as much. I'd say down to… maybe 1Mbit is probably acceptable, although I'd definitely prefer no lower than 4Mbit. At 64kbit you can barely even access their stupid site to buy more volume. You'd think they might implement an exception or something…

Contra (http://www.classicgamesarcade.com/game/21654/contra.html) has loaded today. It's in my "checking games" bookmarks folder on Chrome...

ׂ

I think YouTube has their content distributed around the globe. I'm not sure how many uploads are cached locally like that. But I imagine that most requests are handled without leaving the state, or even the local network as in the case with this video I just watched.

I'm also pretty close to all kinds of major European stuff, from server parks to trans-Atlantic hubs. Physical location doesn't matter that much except for ping, other than that if it's from Asia, it's more likely that there's a bottleneck somewhere along the way.

ׂ

This morning it was to renew my limit (and take my money &all), then I was SURPRISED they blocked me.
You know what? They took certain extra money the other day because my SIM-card sucked net via the neighbouring region (which is not covered by the package).
You see, I called, and yelled at them like they were sunuvabitches...

So, I mean there are certain inconveniencies using SIM modems...

I meant that YouTube is not the best example of gauging network speed because it, like other sites employing Content Delivery Networks, is not transparent about where the content is being served from.

If the video has been cached locally, its speed is not influenced by congestion or traffic shaping further down the line.

Back nearly 10 years ago when I had 100Mbit, the best DC++ speeds were from the LAN and American universities with similar high-speed connections (i.e. 10+MB/s—that's megabyte, of course). In any case, I'm not really following what you're talking about anymore. On 2Mbit, downloading a file or two, no matter from where or for what reason, affects how fast your connection feels. On 10Mbit that's harder to achieve. But I'm going to disagree in that a server that properly fills up your connection, such as YouTube, will make you feel the limits of your connection much better than some stupid bottleneck somewhere down the line in Egypt or Turkey because your file's coming from halfway round the world.

PS I think many YouTube files for Western Europe come from Germany.

ׂ

A data cap on home Internet is retarded.  Mine is 30gb total divided between after hours and peak. So 15gb peak per month.  Wtf? I use more than that on my mobile. I usually reach my cap by day two.

Side note: There are websites that download flash games from about any site. I've done it before because my son likes some flash games and the ads on those sites are usually adult sites I don't want him linked to and blocking page content sometimes blocks the game. It has the added advantage of him not using data too.

I don't know exactly my internet connection velocity. The fastest downloads I ever done reaches around 1.5 to 1.7 MB per second.
It's fast enough for me but usually downloads are slower.

What really irritates me is that there's no way of contracting only a decent internet service, all the three or four ISP illegally forces clients to subscribe some package with internet, telephone and tv included.
When I have the patience I'll suit them all.

I don't know exactly my internet connection velocity. The fastest downloads I ever done reaches around 1.5 to 1.7 MB per second.

That would be something like 12 to 14 Mbit. Although I'm not sure if there's a proper reason why Internet speed is measured in kilobit and megabit while in real life we all use kilobyte and megabyte. I've always suspected it's simply because the value deceptively appears 8 times as large that way. On the other hand, back in the days of 33.6 and 56 kbit modems I guess the measurement made actual sense.

Although I'm not sure if there's a proper reason why Internet speed is measured in kilobit and megabit while in real life we all use kilobyte and megabyte.

I think it's because, theoretically, a byte can consume a variable amount of bits to be transferred (something around 8 bits, it depends on the protocol). Hence, network connections are sold to transfer bits, not bytes, and the speed in bytes depends on how they are packed. (Although, practically, it is almost always the same, I guess.)

Well sure, but there's always about 10% overhead. To say that I'm really getting 50 Mbit while I only actually notice something like 44-45 Mbit is itself also a little deceptive imo. I mean, you can increase the overhead by using encryption, but there's always a bare minimum overhead. To say that I get roughly 5.5 effective MB/s over regular TCP/IP would be far more honest and transparent than saying I get 50 Mbit, with an implied -10%.

And it's not like this is engineers accidentally thinking their customers will know what they're talking about. They seem to have made sure that finding the kind of technical info I'm actually looking for (like are all the ports open, how do I use my own router) is next to impossible.

I think slightly different. They can assure the megabits per second they are able to provide; they cannot assure how much megabytes per second it will result for a customer, according to his usage (encryption etc.). But I agree that they could at least suggest an estimate average speed in megabytes per second (although I have no idea whether this would have legal issues).
And I agree that megabits per second are hard for average customers to understand - beyond knowing that this link has twice the speed of that other.

I think using megabites to be what Frenzie says, a way for deluding consumers presenting a number eight times bigger and therefore in my opinion an attempt of fraud or, at least, deceptive publicity due to the similarity between bites and bytes to a non savvy public.
General public measures the size of a program or download in mega(bytes).

Do automakers presents a car maximum speed in meters per hour? house's areas in square centimeters? a ship tonnage presented in grams?
It would be ridiculous, why are ISPs allowed to do it?
Huge fines applied to them would fix it.

I agree partially. As I said, the ratio bits/bytes per second in data transmission is not a constant number, and so they cannot assure how much MB/s exactly will be delivered. This could have legal issues.

I agree partially. As I said, the ratio bits/bytes per second in data transmission is not a constant number, and so they cannot assure how much MB/s exactly will be delivered. This could have legal issues.

Except what they're advertise is hardly what will be delivered; it's usually more of a theoretical maximum. Belgacom recently switched from advertising a 50 Mbit to advertising a more honest 30 Mbit, with a little asterisk saying over 80% of Belgium will actually be able to obtain 30 Mbit, whereas no more than a third or so at most was able to get 50 Mbit. And if over 80% of customers gets 30 Mbit, then over 80% of customers gets 30 Mbit -10% = ~27 Mbit = ~3.3 MB/s.

In any case, bits per second and bytes per second represent exactly the same thing. One byte is and always will be eight bits. Whenever a download from a slow server is trickling in at 80kB/s, that's just a different, more straightforward way of saying it's trickling in at 640 kilobit/s (excluding overhead). 50 megabit is precisely 6.25 megabyte. Except of course that in practice you won't exceed ~5.5 MB/s. So to say that your theoretical maximum is 5.5 MB/s is clearer and more honest than saying your theoretical maximum is 50 Mbit.

50 megabit is precisely 6.25 megabyte.

Are you sure? As far as I know, overhead counts. Encoding, sometimes, too.

Except what they're advertise is hardly what will be delivered; it's usually more of a theoretical maximum.

Yes. And that's a slightly different subject. (Or the other way around...)

Quote from: Frenzie on 2014-01-29, 12:59:47

50 megabit is precisely 6.25 megabyte.

Are you sure? As far as I know, overhead counts. Encoding, sometimes, too.

Both values include overhead. Divide bits by 8 and you get bytes; multiply bytes by 8 and you get bits.

A 100 Mbit network connection transfers files at an actual speed of ~94 Mbit. That's a mere 6% overhead, but on my PPPoE VDSL connection it's more like 13-14% overhead. (I've been using 10% because that way I can actually do the math in my head, or more to the point do it instantaneously rather than having to think about it.)

So 50 Mbit gives me 50 * .86 = ~43 Mbit of maximum attainable real speed, excluding the lowest possible overhead. Or to phrase it in units people actually use, 6.25 * .86 = ~5.4 MB/s. The exact specifics differ depending on your connection type, of course. But actually, that makes the Mbit values including overhead even more inaccurate—deceptive, I really think I should say. Does it actually matter than one 50 Mbit might mean a maximum real speed as high as 5.8 MB/s while another 50 Mbit could be as low as 5 MB/s? Probably not in practice, but it does illustrate something, doesn't it?

Yes, it does.
It seems, almost, that we are saying the same thing, but we disagree on what the megabits mean. Let's see:

A 100 Mbit network connection transfers files at an actual speed of ~94 Mbit.

Yes.

Divide bits by 8 and you get bytes; multiply bytes by 8 and you get bits.

This is correct if you mean the ~94 Mbit instead of 100 Mbit. But I'm referring to the 100 Mbits. You get 100 Mbits of total bits transferred, including overhead, which will result in ~94/8 effective MBytes transferred to/from your machine. I think we agree on this.
For me, the problem is the "~". The network company is responsible for the exact amount of total bits it is able* to deliver, but cannot (or can?) respond for some exact amount of bytes that will be effectively delivered.

(For the record... when I used dial-up, some years ago, I used to get more accurate download rates dividing the kbps by 9.)

* But I agree that, failing to deliver the advertised speed, this is really deceptive.

Quote from: Frenzie on 2014-01-29, 14:00:38

Divide bits by 8 and you get bytes; multiply bytes by 8 and you get bits.

This is correct if you mean the ~94 Mbit instead of 100 Mbit. But I'm referring to the 100 Mbits. You get 100 Mbits of total bits transferred, including overhead, which will result in ~94/8 effective MBytes transferred to/from your machine. I think we agree on this.

Sure, but including overhead you also have 100/8 total megabytes* transfered per second.

For me, the problem is the "~". The network company is responsible for the exact amount of total bits it is able* to deliver, but cannot (or can?) respond for some exact amount of bytes that will be effectively delivered.

If you know the standard IP packet size, the amount of bits added by TCP/IP overhead, and the additional overhead added by e.g. PPPoE and ATM (and we know precisely how many octets (http://maxolasersquad.com/network/chapter18.html)**), I don't think there's a ~, or at least not in the sense you mean. I simply say ~ because I neither need nor care to perform such calculations.

I'm pretty sure that 50 Mbit/s is also ~50 Mbit/s, but in a slightly different sense, because the data is actually sent along the wire huddled together in groups, each of which takes so many µs to encode and send along in VDSL form. And I'm reasonably sure the time involved is a "nasty" value like 21 µs*** and not a "nice" value like 20 µs. Besides, some such groups might be lost or damaged due to interference occasionally. The primary difference here is that 50 Mbit/s has a significantly smaller error margin than the rough calculations I did by positing 14% overhead (let alone 10% overhead). Just think of it as similar to treating Pi as 3.14, 3.1, or even just plain 3 if you all you need is a quick estimate.

(For the record... when I used dial-up, some years ago, I used to get more accurate download rates dividing the kbps by 9.)

Naturally. 56 kb/s - roughly 10% overhead = ~50 kb/s real speed, which is 50/8 = ~6 kB/s. Dividing by nine is basically operating on an assumption of 11% overhead, but by rounding down I too am operating with what is more 11-14% than 10%.

*  I should probably be saying mebibytes, but I still think that sounds weird. In any case, it makes no difference here. Whether it's 1000 bytes or 1024 bytes, you still get bits through multiplication by 8 and vice versa.
** I'm not being very precise in my vocabulary. I'm using Mbit to mean Mb/s, megabyte to mean mebibyte, and byte to mean octet. None of those are unusual, mind you.
*** NB I'm not saying it's 21 µs.

I'm possibly misunderstood here, because I'm not talking about accurate calculations or measures. I refer to the way how bytes are transferred through a serial media, i. e. an internet link. Maybe I'm fairly outdated, but I'd like to know.
In ancient times, you needed to transfer bytes with a significant overhead, for instance, 7 bits + 1 parity bit + 2 stop bits, 8 bits + 1 stop bit and anything else like that. In the latter case, in order to transfer 1 byte, you needed 9 bits. If the line speed were 28800 bps, the effective* speed in bytes in this case would be 3200 bytes per second, not 3600 bytes per second. With different overheads, the effective speed in bytes would be slightly different. In any case, the line speed could be assured to be 28800 bps, no matter how the bytes were encoded.
Looking at the link you provided, it seems that modern internet links always use 8 bits per byte, with a well known overhead in low levels. This is good. But it says that other services in higher levels and application-level protocols introduce even more overhead, and it means to me that the effective** speed in bytes perceived by the user depends ultimately on what he's doing.
Finally, this is why I'm saying that an advertised speed in megabits per second is a safe value, for which the company can and should be responsible to deliver, even though it has little meaning to the average customer, while an advertised speed in megabytes per second is an unsafe value, which depends highly on how the link is used and perceived by the customer, and I fail to see how a company could be legally responsible for that.
I thank you very much for your precious information.

* Here I mean effective in low levels.
** Here I mean effective how perceived by the user.

128kbps? Well, at least it's better than the 64kbps to which they drop mine. :right:

When they drop you there, for how long do they keep it so until you get the speed up again without asking?

I'm possibly misunderstood here, because I'm not talking about accurate calculations or measures. I refer to the way how bytes are transferred through a serial media, i. e. an internet link. Maybe I'm fairly outdated, but I'd like to know.
In ancient times, you needed to transfer bytes with a significant overhead, for instance, 7 bits + 1 parity bit + 2 stop bits, 8 bits + 1 stop bit and anything else like that. In the latter case, in order to transfer 1 byte, you needed 9 bits. If the line speed were 28800 bps, the effective* speed in bytes in this case would be 3200 bytes per second, not 3600 bytes per second. With different overheads, the effective speed in bytes would be slightly different. In any case, the line speed could be assured to be 28800 bps, no matter how the bytes were encoded.

It looks to me like you just accurately calculated the maximum possible actually relevant speed. Anyway, you know too much about the subject, and that is something I did not realize—although in a footnote I did say I was using the word byte to mean octet. Your bytes include parity bits and start bits and stop bits, which is sensible enough in the proper context.

I fail to see how a company could be legally responsible for that.

There's only one, one, ISP that I know of which obviously says they offer up to 40 Mb/s without hiding in small print somewhere that you might only get as little as a few Mb/s, and you're wondering whether saying the much more meaningful up to 4.3 MB/s (excluding 14% overhead) is legally defensible? I sincerely hope you're devastatingly wrong. But to return to Belfrager's example of cars, it would seem that by your reasoning it would be impossible for cars to advertise their efficiency in L/100 km. And actually, I believe you can make a much stronger case that L/100 km doesn't reflect typical driving conditions than that a regular HTTP connection doesn't reflect typical Internet conditions.

Quote from: Frenzie on 2014-01-21, 18:50:37

128kbps? Well, at least it's better than the 64kbps to which they drop mine. :right:

When they drop you there, for how long do they keep it so until you get the speed up again without asking?

Until the end of the month or until you pay for more volume. I could also get unlimited for €7/month,* which is not a horrible price. But, frankly, not worth it. Our former ISP would drop us to 2 Mbps after crossing their limit, which was much more pleasant but for saving €9/month and significantly higher speeds it seemed worth it. Well, still does. On ADSL, despite an alleged maximum possible speed of 21 Mbit (if you live in the telephony exchange, I imagine), we never got more than 4-6 Mbit. And I have to say, on today's web that was starting to feel rather slow.

Anyway, I'd gladly take half the speed and at least twice the volume. Speed is fairly irrelevant past a certain threshold. For instance, a YouTube 1080p video goes at 8 Mbit/s, so at 20 Mbit/s you can comfortably watch two at once while doing something on the side. Having more speed than that doesn't serve too much of a practical purpose, although there are HD streams at higher bitrates. Anyway, I very much hope that an entity like Netflix will take the providers to court over unfair competition because the provider's own TV over IP doesn't count toward any limits. I also firmly believe they've negatively affected Belgium's competitive ability, because a bandwidth-intense service like Google Maps could've never been developed here with ludicrous limits like 30 GB which they used only just a few years ago. We went with our former provider simply because they were the only one with a usable limit.

* There's plenty of reports of people going over 1.5 TB with the unlimited plan, and a few going over 3 TB, so it's not your idiotic 500 GBish "unlimited fair use" either.

I did say I was using the word byte to mean octet. Your bytes include parity bits and start bits and stop bits, which is sensible enough in the proper context.

Well, a byte is always an octet. The way how bytes are serialized (transmitted) may require a different amount of bits, depending on the serial protocol. This is why I'm saying that the ratio between bits transmission speed and effective bytes transmitted is not a fixed obvious integer number (or something like that, you get the idea).

I sincerely hope you're devastatingly wrong.

I do, too. :) I sincerely say that I simply don't know.

by your reasoning it would be impossible for cars to advertise their efficiency in L/100 km.

Well, it seems you are right. If cars can advertise that, then network providers would be allowed - and even recommended - to advertise an expected speed in megabytes under typical internet conditions.

Well, a byte is always an octet. The way how bytes are serialized (transmitted) may require a different amount of bits, depending on the serial protocol. This is why I'm saying that the ratio between bits transmission speed and effective bytes transmitted is not a fixed obvious integer number (or something like that, you get the idea).

I don't think the theoretical maximum possible effective/serialized bandwidth I mentioned is the value ISPs should advertise, but I do think it'd be more relevant to the consumer. Going by the site I linked earlier, the maximum possible effective bandwidth would have ~13% overhead, while I say it's more like ~14% overhead due to HTTP. Call it ~15% overhead for SSL, add a disclaimer that you're only talking about files of at least 10MB in size so things like headers and keys are negligible, and in my view you have a fair description of the real speed in terms that actually matter and mean something.

Anyway, I thought an octet was just any old 8 bits. You're saying that in networking jargon the throughput is only in bits while the goodput is only in bytes or octets?

Well, it seems you are right. If cars can advertise that, then network providers would be allowed - and even recommended - to advertise an expected speed in megabytes under typical internet conditions.

I'll add that at least some ISPs advertise that it'd take e.g. 5 minutes to download a movie, or 1 second to download a song, yet they don't even specify what size movie or song they're talking about. You'd assume it's based on some guestimate about the average size of iTunes purchases, but who knows? It's a bit as if a car maker advertised that you can drive from Amsterdam to Rome on a full tank of gas. It sounds superficially meaningful, but I'd rather know the L/100 km and the capacity of the tank.

Anyway, I thought an octet was just any old 8 bits.

Yes, it is.

You're saying that in networking jargon the throughput is only in bits while the goodput is only in bytes or octets?

More or less. No one cares about bits. We want bytes. We use bytes. But serial media don't transmit bytes - they transmit bits. And the maximum speed that media can transmit bits depends on its physical properties and on the devices that handle that media in each end. That speed in bits per second is well known, is standardized, and is real. So, we need some way to send and receive bytes serially, and that's why some overhead is added to distinguish the current byte from its previous byte and so on.
Bytes exist in each end of the line, but not inside the line. Depending on the type of media, more or less bits are needed/added to assure the quality of transmission (that the bytes that are sent will be effectively received at the other end). I think that's why ancient slow serial lines required a lot of serial protocol overhead (parity bits, stop bits), while modern serial lines don't require that much.

(Ah, poo-typing...) Got a cable - now "testing": the rate is 100Mb/s (announced), but rather often it feels like much less, though it works!