[00:46] *** dwarren has quit IRC (Read error: Connection reset by peer) [00:47] *** dwarren has joined #arpnetworks [01:56] *** dwarren has quit IRC (Read error: Connection reset by peer) [01:57] *** dwarren has joined #arpnetworks [01:57] *** mnathani has quit IRC (Ping timeout: 265 seconds) [01:57] *** mnathani has joined #arpnetworks [02:19] Are there any conventional tiers of RTT latency? (eg., 0-30ms, >30-60ms, ..) [02:20] The only non-arbitrary basis for that that I can see at present is classes of applications based on latency, such as VOIP vs HTTP [02:22] https://en.wikipedia.org/wiki/Traffic_classification#Typical_traffic_classes is the nearest I've found, and it's based on logical application rather than latency, although that's implied [02:22] Traffic classification :: Traffic classification is an automated process which categorises computer network traffic according to various parameters (for example, based on port number or protocol) into a number of traffic classes. Each resulting traffic class can be treated differently in order to differentiate the service implied for the user (data generator/ consumer). Typical uses Packets are classified to be differently processed by the. [02:26] Interesting traffic introspection product read BTW: https://www.sandvine.com/downloads/general/sandvine-technology-showcases/traffic-classification-identifying-and-measuring-internet-traffic.pdf [03:28] don't think there is kelly.. [03:28] jitter is usually referenced more than rtt.. [03:28] as rtt can vary depending on distance [03:29] i used to disapprove of networks with more than 0.5 msec jitter in normal operation. [03:29] but there are just way too many factors.. [03:31] That's quite a tight tolerance [03:31] but in a very round about way, things like 2 msec jitter mean that there is more network load, which means the chances of upstream congestion issues in the near future is higher [03:31] yeah - things like virtualisation, coalescing etc can add a little bit of jitter which doesn't necessarily impact [03:32] I like how high jitter exposes providers with inadequate network capacity at certain times of a day. [03:32] It's also why I value throughput monitoring [03:32] the thing is it's usual for jitter to go up a little as networks are getting into higher utilisation %'s.. which can suddenly lead to severe issues [03:32] well i like the idea of small file throughput monitoring still [03:32] I dislike over-subscription personally [03:32] That's what I mean [03:32] vultr sydney has had congestino issues since it started, but it's in the upload direction... [03:33] well it was in both directions for a while. [03:33] Up/down is a great distinction. I'll make a note of that [03:33] but it varies where it's from, a lot of weird issues, ... if you want somewhere weird to test from [03:34] err uploading to vultr is bad i mean [03:34] rather than downloading to it [03:34] err downloading from it [03:34] which suggests either people torrenting from it, or it sharing bandwidth with some isp work loads :) [03:35] the problem is most providers have more than one provider, and providers can have different issues in different locations [03:36] also it depends what you're doing, i stopped doing throughput monitoring mostly when 2 or 3 megabytes/sec was easy [03:36] because after that it stops mattering a lot more.. [03:36] Latency, jitter, packetloss, throughput up/down. Can you think of other fundamental attributes of network performance? [03:36] if you're getting 300k/sec it matters a lot more [03:36] mmomentary network outages [03:37] My idea for that was to have 1MB file transfers frequently, with 10MB less frequently, and 100MB infrequently [03:37] Thoughts? [03:37] well i do 200k [03:37] and i find it hilights any issues fine [03:37] and i do 10mb manually sometimes [03:37] That's what she said!! [03:37] That's good to know [03:37] That's what she said!! [03:37] i don't really think you need to do more than that [03:37] if it takes 2 seconds to download 200k when it usually takes 1 second there is degraded network performance [03:37] it doesn't really matter how fast you get now days [03:38] True [03:38] it's more important to catch issues [03:38] and doing lots of 200k donwloads can still burn off 200gb of data ors omething [03:40] Jitter is the standard deviation of a series of RTTs, correct? [03:41] http://www.cisco.com/c/en/us/support/docs/voice/voice-quality/18902-jitter-packet-voice.html [03:42] actually that site sucks [03:42] jitter is basically the difference between median and mode i think, but don't hold me to that [03:47] In plain terms, do you look at jitter as the standard deviation? To identify how much the latency varies [07:24] *** Hien_ has quit IRC (Quit: leaving) [07:24] *** Hien has joined #arpnetworks [07:26] *** Hien has quit IRC (Client Quit) [07:28] *** Hien has joined #arpnetworks [21:10] anyone know what it means when a thinkpad is stuck on battery light and z with circle indicator [21:37] the screen turned to static like pixels the last time it was on. [21:37] I really hope it isn't dead [21:53] maybe a short? [21:53] that's just a random guess though