#arpnetworks 2014-12-23,Tue

↑back Search ←Prev date Next date→ Show only urls(Click on time to select a line by its url)
WhoWhatWhen
acf_I think this was the thing where the connection between ARP and his Comcast line was slow...
over IPv6
we determined that it could have been HE
http://irclogger.arpnetworks.com/irclogger_log/arpnetworks?date=2014-12-11,Thu&sel=34#l30
^ that's the testing we did 		[00:19]
***kevr_ has quit IRC (Quit: ZNC - http://znc.in)
kevr has joined #arpnetworks 		[00:24]
up_the_ironsah i c [00:38]
mercutiois that ntt->verizon ipv4 congestion still happening?
i wonder if he sends a lot of traffic to comcast
considering they both do a lot of ipv6
it may just be a congested link
which means it may not get fixed until next yera 		[00:39]
acf_very little NTT -> Verizon congestion shows up on smokeping now [00:47]
mercutiocool.
it was kind of disturbing that happened for so long 		[00:47]
BryceBotThat's what she said!! [00:47]
acf_yea [00:47]
mercutiowell not as disturbing as comcast.. [00:48]
acf_it was replaced with Amazon EC2 -> Verizon congestion :P [00:48]
mercutioerr cogent
damnit, i go tthe two mixed up.
heh.
amazon is lame :)
i used to have terrible speeds here from amazon east coast.
which seems to be where most stuff is 		[00:48]
acf_looks like the Verizon <-> Comcast congestion is gone too? [00:49]
mercutioi have no way to test that
but it'd depend on city too i imagine 		[00:49]
acf_http://unixcube.org/who/acf/tmp/comcast-net.png [00:49]
mercutiowhat's that
uhh 		[00:50]
acf_an ad from Comcast
afaik it's legit
probably they want their TWC merger to go through... 		[00:50]
mercutiocongestion is such a complicated issue
netflix kind of hilighted it. 		[00:50]
BryceBotThat's what she said!! [00:51]
mercutiobut it's happened many times over the years.
i kind of like the fact that cogent let it happen in a way.
cos it brought it to attention more. 		[00:51]
acf_I think it was also a stupid thing for them to do [00:52]
mercutiobut at&t, verizon, comcast etc are all evil [00:52]
acf_also they still don't IPv6 peer with HE [00:52]
mercutioit's fine as long as your isp isn't using cogent :) [00:53]
acf_I wonder how much of that congestion we had been seeing there was from Netflix [00:53]
mercutioit's complicatged.
but after private peering normal cogent stuff got better 		[00:53]
acf_also I believe NTT was a transit provider for Netflix [00:54]
mercutiobut who's to know how much the traffic hurt their network internally [00:54]
acf_Comcast's network? [00:54]
mercutioi haven't been following US news, what's happening now with regards to government net neutrility?
nah cogent's network
they were doing qos 		[00:55]
acf_oh that's right
I think they were doing that just for peering though
not because of their backbone 		[00:55]
mercutiothe real solution is to run links at < 50% utilisation
and upgrade them when they're nearing 50%
so that you can handle failures, and spikes. 		[00:56]
BryceBotThat's what she said!! [00:56]
acf_right. but cogent was being their usual asshole self and didn't want to negotiate that [00:56]
mercutioprobably not both at once :)
well it should be funded by both sides equally 		[00:56]
acf_well, I guess a lot of people were in that boat this time [00:57]
mercutioi think it's reasonably to not carry traffic a long distance.
the only way the net is going to work well is if large companys can't charge smaller companies to send them data.
or charge unreasonable fees at least.
otherwise only large companies can exist, and bandwidth prices go up, and bandwidth is seen as being in short supply and valuable.
which means conservation of bandwidth and slowing economy. 		[00:57]
acf_that has only happened with eyeball networks so far
lots of competition for transit still 		[00:58]
mercutiowell verizon, at&t, comcast etc are all just as bad as each other. [00:59]
acf_yea, they're the bad ones
I don't know if it's completely unreasonable to request payment for traffic though 		[00:59]
mercutiofor carrying traffic sure [00:59]
acf_it follows the "sender pays" model we've always had [00:59]
mercutiolike if a user is in new york, and a sender is in los angeles, it's reasonable to expect them to carry the traffic to new york. [00:59]
acf_right [01:00]
mercutioor to pay someone else to carry it to new york.
but if a user is in east/south side of canada, it's not unreasonable to want to dump it in new york too
and expect the isp to pick it up from there.
but that's where it gets tricky.
how many places should you offload data.
like amazon don't pay to send data to new zealand, they offload it in the US...
interesting enough, microsoft pay to send data to new zealand, and offload it in NZ..
and microsoft have free peering 		[01:00]
acf_so I suppose it depends on the source / destination of the traffic?
billing would have to change a lot.. 		[01:03]
mercutiowell basically senders should send data as close to the end user as possible in an ideal world.
but you can't expect them to be in every little city. 		[01:04]
acf_yea [01:04]
mercutiobut if you're doing more than 500 megabit in a city, it's not unreasonable to offload data there.
and to make that work well, you need to reduce the cost of mpls links, and remote data centre ports etc.
and i think that's where things are slowly moving towards. 		[01:04]
acf_so you think things could resolve themselves over time? [01:06]
mercutionot necessarily.
if you can charge $10,000 for a gigabit, or charge $0 for a gigabit, what would you rather? 		[01:06]
acf_right. but that's if the telecom monopolies control all the links
otherwise the pricing should become competitive 		[01:06]
mercutiobut if you want to send 16 megabit video to 1000 users, it's reasonable to have your own connection into that city. [01:07]
acf_so how to ensure people are being "reasonable"? [01:07]
mercutioand it's up to you if you want to do it as 10 gigabit, or gigabit with smarts for uplink capacity to the city.
by encouraging "local peering"
isp's like verizon/comcast should have to advertise ip's within 100 miles or osmething.
and provide free peering. 		[01:07]
acf_ah I see [01:08]
mercutiodistance is just the easiest metric.
i heard somewhere that cogent were being extra nasty about where they were offloading data
and i've heard of other companies doing similar. 		[01:08]
acf_"extra nasty"? [01:09]
mercutio"unreasonable" [01:09]
acf_ah, so like they pick up the traffic from a customer in LAX, then offload it onto Verizon in LAX? [01:09]
mercutiolike if you want to dump lots of data, it's good to do it somewehre like dallas, california, new york, illinois, flordia etc.
where there are major interconnects already in place. 		[01:09]
acf_why is that nasty though? [01:10]
BryceBotThat's what she said!! [01:10]
mercutioit's not so reasonable to dump lots of traffic in kansas or such. [01:10]
acf_oh yes [01:10]
mercutiobecause in smaller areas there's less infrastructure
or less central points. 		[01:10]
acf_why would they want to do that though?
I can't imagine it would be cheaper 		[01:10]
mercutiokanasas is a backup route anyway i think
because netflix can host their shit anywhere.,
but yeah it's not cheaper.
it's just more rude. 		[01:10]
acf_so they're paying more to be rude [01:11]
mercutiowell i think it's more complicated than that [01:11]
acf_I would imagine..
apparently President Obama wants to regulate consumer Internet access as a telecom service
that's the latest plan here 		[01:11]
mercutiosome target like 500 megabit is just a good way to make sure there are more interconnects.
but basically there shoudl be shit loads of interconnects, and transit providers giving cheap transit to those locations.
what city are you in? 		[01:12]
acf_Orcutt, CA
tiny city between LAX and SFO
Verizon goes via LAX, Comcast goes via SJC 		[01:13]
mercutioso santa maria is the nearest location? [01:13]
acf_yea [01:13]
mercutioso santa maria looks like somewhere an interconnect should happen [01:14]
acf_how would that happen?
there is no datacenter or anthing... 		[01:14]
mercutiohmm checking population
so yeah it's a bit over 100k 		[01:14]
acf_there is a private DC nearby in San Luis Obispo, CA [01:14]
mercutiohere it happens in telephone exchanges. [01:14]
BryceBotThat's what she said!! [01:14]
acf_Verizon DSL traffic all gets tunneled to the router in SLO
but Verizon doesn't peer there 		[01:15]
mercutiodsl is legacy
what happens when you get fibre 		[01:15]
acf_I think there aren't transit providers there actually
I think Verizon stopped rolling out fiber
too expensive, they didn't really care anyway 		[01:15]
mercutiohttp://fibrebuild.fibrenet.it/en/fibre-net-a-successful-completion-for-the-restoration-of-santa-maria-assunta-abbey-in-san-gimignano/
oh
wrong fibre 		[01:16]
acf_:P [01:16]
mercutioverizon should terminate ports closer :/
100,000 population is enough to terminate ports locally 		[01:16]
acf_change is probably very difficult for them [01:17]
mercutioso yeah it means they need to provision bng's locally.
yeah. 		[01:17]
acf_they're big, and have old things
I think they might do static routes all the way to LA 		[01:17]
mercutiobut yeah ok ideally they should be terminating on bng's closer.
where is SLO? 		[01:17]
acf_bng? [01:17]
mercutiopppoe termination
or ppp
as well as dhcp etc. 		[01:18]
acf_40 miles from here
opposite direction of LA though 		[01:18]
mercutiohttp://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r4-3/bng/configuration/guide/b_bng_cg43xasr9k/b_bng_cg43asr9k_chapter_01.html
still not that bad.
ok that odesn't make it easier.
hmm
40 miles i suppose that's not too bad then.
ok so say SLO should have interconnects then 		[01:18]
acf_yea
they even have a DC, etc... 		[01:19]
mercutiois there other providers other than verizon? [01:19]
acf_AT&T [01:19]
mercutioso verizon and at&t should peer there too. [01:19]
acf_but I believe that datacenter leases lines to LAX and SJC [01:19]
mercutioand traffic shouldn't have to go via sjc/lax [01:19]
acf_no real providers have presences there
oh also Comcast
yea. that would be good 		[01:19]
mercutioand anyone else that wnats to peer [01:20]
acf_I'd guess adding a ton of peering points like that would vastly increase their network complexity [01:20]
mercutioand if netflix wants to send data to users it should host something there
like their own cache 		[01:20]
acf_possibly adding more points of failure? [01:20]
mercutioit's not really more complex.
it's more things to go wrong, but also more redundancy 		[01:20]
acf_I suppose
certainly Verizon would have to change a lot of their crap 		[01:21]
mercutioif users stay connected and fibre is servered they can still talk to each other
but yeah this is ideal speaking
rather than money speaking
chances are that gigabit peering would be fine for the location atm
but it'd be nicer to provision 10 gigabit switches, and get some provider to pay for them :/
err like ciscso or juniper or something
but yeah even with isps's like at&t, verizon etc, local traffic would probably be fine on gigabit atm
until users get faster connections 		[01:21]
acf_https://www.google.com/maps/@36.3807012,-119.2606125,7z/data=!4m2!6m1!1szKX6_3rmHouE.k3rceCRgcUQs
can you see that? 		[01:23]
mercutiobut as connections go up to gigabit etc, it'd be nice to be able to shift data quickly between providfers. [01:23]
acf_that's my Comcast -> ARP path [01:23]
mercutiohmm i don't see a path
you may have to do copy link url
it seemed to get rid of the end bits hmm
and changes to maps.google.com 		[01:23]
acf_https://www.google.com/maps/d/edit?mid=zKX6_3rmHouE.k3rceCRgcUQs
that should work
you can see San Luis Obispo on there too
my Verizon traffic goes to there, then straight to LAX
but the latencies are about equal, because of the DSL FEC stuff
also Verizon DSL has huge queues
rtt goes up to 10 seconds when downloading a file 		[01:24]
mercutionetflix's idea is that you host your own google caches.
err own netflix caches.
using your power etc?
it's better to have something that covers whoever wants to send you data
and they pay for transit to the location
we don't realyl have buffer bloat issues in this country, its' weird.
because a lot of people are running short queues, and it can impact international performance. 		[01:27]
acf_I think google has done that with YouTube for a while [01:28]
mercutioyeah that worked
is there no cable from santa maria to santa barbara to santa clarita etc. 		[01:28]
acf_I'm sure there is
maybe it's not Comcast's though
or their routing just sucks
there is a cable owned by Level3 that goes that way.. 		[01:29]
mercutioso yeah taking a wide stab in the dark, modesto, fresno, santa maria, santa barbara, santa clarita, lancaster etc should ll have interconnections.
i wonder what lancaster's population is like
156,633
in 2010
so yeah, big enough 		[01:30]
acf_that certainly would be good [01:31]
mercutionew zealand has actually got quite good peering in general.
and the US has quite bad peering :) 		[01:31]
acf_yea [01:31]
mercutioalthough a friend of mine runs a wireless isp and there's no peering in his vity.
city.
but it's like 50k people or something
with some surrounding towns
hmm 74k
no public data centres etc, closest is telephone exchange 		[01:31]
acf_I think Verizon, AT&T, etc... make peering in telephone exchanges way too expensive [01:33]
mercutioyeah.
well those are already there. 		[01:33]
acf_there is a law that says CLECs have to rent you space in their COs [01:33]
mercutioand that's where government could step in.
it's expensive here too. 		[01:33]
acf_but your stuff has to be 48v powered [01:33]
mercutiobut people have connections in there anyway.
that's not a bad thing. 		[01:34]
acf_and it's super expensive, and all your equipment has to be approved by them [01:34]
mercutiothey probably have dslams there anyway? [01:34]
acf_they do [01:34]
mercutioso yeah, as well as a dslam, adding a bng there. [01:34]
acf_I got to visit a US CO once
those telephone switches are huge 		[01:35]
mercutioapparently juniper are adding bng functionality to mx80s. [01:35]
acf_I wonder how much motivation the CLECs have to do any sort of network improvement [01:36]
mercutioat least here it can take ages to get stuff permitted to be installed too. [01:36]
acf_I'd guess most of their revenue comes from cell backhaul, MPLS, etc...
*ILEC 		[01:36]
mercutiohard to know. [01:39]
acf_that reminds me
when I was having that Verizon packet loss issue
with the NTT peering
there was also internal Verizon packet loss 		[01:39]
mercutiothis country is surprising me with how much network improvements have been happening
apparently 200 megabit is the new target.
it wasn't that long ago that 20 megabit was rare. 		[01:40]
acf_Comcast is doing OK here
also Google is trying to compete 		[01:40]
mercutiooh is it you i have been smokepinging for ages? [01:40]
acf_idk. my IP probably has changed :P [01:41]
mercutioherh
maybe
but it'll be someone else nearby :/ 		[01:41]
acf_yea
I actually got Verizon to fix their things
by calling them 		[01:41]
mercutiohmm snloca [01:41]
acf_formerly my Verizon IP [01:42]
mercutiocool. [01:42]
acf_snloca == San Luis Obispo [01:42]
mercutioyeah.
so yeah it was stable for me for ages :)
but i think my uplink was via verizon
oh it's via level3 now
so i think level3 are passing to verizon in los angeles
and that seems long enough distance wise, that if two people had fibre connecting locally would be faster.
err would be noticably faster.
that dsl interleaving sucks :/ 		[01:42]
acf_yea
I tried to get them to turn it off once.. they didn't 		[01:46]
mercutiowhy wouldn't they? [01:47]
acf_"not supported" [01:48]
mercutiolame
is it vdsl or adsl? 		[01:48]
acf_adsl [01:48]
mercutiono excuses then :)
does vdsl have the same interlaving? 		[01:49]
acf_they don't offer vdsl here [01:49]
mercutioand is it fixed delay, or depending on sync rate? [01:49]
acf_I'm close enough to the CO to be able to get it though [01:49]
mercutiothat sucks.
i have vdsl. 		[01:50]
acf_I'm not sure about that
I've never been able to see my modem stats
but I can't remember it ever changing 		[01:50]
mercutiobut adsl here shifted from fixed intearleaving delay to a kind of adaptive one
and if you reduced your snr margin you could reduce delay. 		[01:50]
acf_hmm interesting [01:50]
mercutiooh you can't see your modem stats. [01:50]
acf_I think it's fixed here [01:50]
mercutioi've been snr tweaking adsl for years. [01:51]
acf_most people here have a modem with integrated router. I don't [01:51]
mercutionormal sync rates are around 16 to 18 megabit here
but with snr tweaking can be 21 to 23. 		[01:51]
acf_how do you accomplish that? [01:51]
mercutioon broadcom chipsets you just telnet into modem and do "adsl configure --snr 65480 or such"
if you have snr margin of 12
and it'll go to like 3 or 4 or something.
or low normal numbers to do less than 6db diff 		[01:51]
acf_what? how do you adjust that in software? [01:52]
mercutioit's like the lower the better [01:52]
acf_adjusting tx power? [01:52]
mercutiounless you go to like 65000+ :)
it doesn't adjust power
like i have adsl as well as vdsl
http://pastebin.com/i8MqgwDF
so that training margin of 8 means it's less of a tweak than i used to do
http://pastebin.com/gzEaEvpp

and it ends uip with sync of 22 megabit'ish. 		[01:52]
acf_oh I see [01:55]
mercutiowith no interleaving. [01:55]
acf_adjusting "training margin" enables faster line rates
what kind of latency do you get? 		[01:55]
mercutioyeh.
about 10 msec on adsl and 5 msec on vdsl 		[01:55]
acf_oh nice
looks like I get 30 ms with interleaving 		[01:55]
mercutioi want lower :) [01:56]
acf_I get 8 ms on DOCSIS [01:56]
mercutioi used to get 20 msec with interleaving.
docsis2?
i think a lot of that 8 msec is getting to los angeles or san jose 		[01:56]
acf_no [01:57]
mercutioit's the jitter that hurts with docsis though [01:57]
acf_just to the local node [01:57]
mercutiothat seems high. [01:57]
acf_ummm... [01:58]
mercutioalso my vdsl is screwed atm because i have bad wiring [01:58]
acf_"Cable Modem Status Offline" [01:58]
mercutioand it added 8 msec interleaving downstream :(
after fixing cable. 		[01:58]
acf_looks like DOCSIS 3 [01:58]
mercutiodocsis3 is actually a lot better than docsis2 [01:58]
acf_1. c-67-180-12-1.hsd1.ca.comcast.ne 0.0% 10 9.0 10.5 7.9 22.7 4.8
7.9 ms best 		[01:59]
mercutioyou have two lines? [02:00]
acf_Verizon and Comcast
my Verizon line is cheap, and bundled with phone
but it sucks 		[02:00]
mercutioso it's like backup? [02:01]
acf_yea
I don't think I've ever seen it completey fail
I've seen the Comcast one fail several times actually 		[02:01]
mercutioheh
there's only one cable network in new zealand, and it used to fail heaps.
but have much lower delay than adsl.
until the interleaving stuff got sorted. 		[02:02]
acf_that's how it is here now [02:03]
mercutiothen it was kind of worse to my mind [02:03]
acf_but it's not *too* much failure.. only like four times a year, for a couple of hours :P [02:03]
BryceBotThat's what she said!! [02:03]
mercutiothen more stuff shifted to docsis 3
and prices came down
and i think it's ok now.
they also had nasty transparent proxies
that would severely limit download speeds.
like 100 megabit connections that would do 300k/sec to the UK 		[02:03]
acf_oh super [02:04]
mercutioyeah i did some tests with iperf for someone.
err with someone
and udp was fine. 		[02:04]
acf_Comcast tried injecting TCP FIN s for BitTorrent connections once
people got really pissed 		[02:05]
mercutiobut tcp/ip was shit.
but http was even worse.
i think that was partially queuing issues
i care more than i should about such things.
but on connections with short queues, often artificially capping the speed you send at them will speed up downloads.
especially on rate limited faster connections. 		[02:05]
acf_I got that working on my Verizon DSL line actually [02:06]
mercutiolike if you have 200 megabit connection sold at 30 megabit etc.
well that was to work around delays? 		[02:06]
acf_work around the huge queues [02:07]
mercutioyeah.
here queues are less than 20 msec normally
like uhh
axel -a to local server jumps it up from 13.6 msec to 26.7 msec 		[02:07]
acf_not too bad [02:08]
mercutioand 10 to 28 on adsl.
actually adsl was sometimes a bit lower than that too
yeah it's not too bad except that it can stall transfers and give losss easily 		[02:08]
............................ (idle for 2h16mn)
***RandalSchwartz has quit IRC (*.net *.split)
jpalmer has quit IRC (*.net *.split)
Hien_ has quit IRC (*.net *.split)
staticsafe has quit IRC (*.net *.split)
up_the_irons has quit IRC (*.net *.split)
NiTeMaRe has quit IRC (*.net *.split)
tellnes has quit IRC (*.net *.split)
meingtsla has quit IRC (*.net *.split)
twobithacker has quit IRC (*.net *.split)
hazardous has quit IRC (*.net *.split)
eryc has quit IRC (*.net *.split)
JC_Denton has quit IRC (*.net *.split)
medum has quit IRC (*.net *.split)
anisfarhana has quit IRC (*.net *.split)
pjs has quit IRC (*.net *.split)
mike-burns has quit IRC (*.net *.split)
dwarren has quit IRC (*.net *.split)
jlgaddis has quit IRC (*.net *.split)
RandalSchwartz has joined #arpnetworks
jpalmer has joined #arpnetworks
Hien_ has joined #arpnetworks
staticsafe has joined #arpnetworks
up_the_irons has joined #arpnetworks
tellnes has joined #arpnetworks
meingtsla has joined #arpnetworks
twobithacker has joined #arpnetworks
sinisalo.freenode.net sets mode: +o up_the_irons
hazardous has joined #arpnetworks
eryc has joined #arpnetworks
JC_Denton has joined #arpnetworks
medum has joined #arpnetworks
anisfarhana has joined #arpnetworks
pjs has joined #arpnetworks
mike-burns has joined #arpnetworks
dwarren has joined #arpnetworks
jlgaddis has joined #arpnetworks
sinisalo.freenode.net sets mode: +o mike-burns
NiTeMaRe has joined #arpnetworks 		[04:25]
................ (idle for 1h17mn)
qbitup_the_irons: https://github.com/iojs/build/issues/1#issuecomment-67944799 <-- re the iojs build stuff we talked about a while back
dunno if that's enough to justify it for ya :D 		[05:46]
mhoranup_the_irons: Did you do something? Because now throughput is just as fast on v6/v4. Or maybe it's a time of day thing? [05:54]
............................................................ (idle for 4h55mn)
***awyeah has quit IRC (Quit: ZNC - http://znc.in)
awyeah has joined #arpnetworks 		[10:49]
..... (idle for 23mn)
mercutiomhoran: i wouldn't be surprised if it's time of day related. [11:14]
mhoranSlower now, but not as slow as last night / last time we looked into it. [11:15]
.......... (idle for 45mn)
mercutiowell it is xmas.
i imagine less business users using the net at least.
i dunno if it was business or residential peak 		[12:00]
setup smokeping with curl :) [12:07]
..... (idle for 20mn)
brycecWhere in the world is it already xmas??? 11:59:49 mercutio | well it is xmas. [12:27]
mercutioit's "xmas period"
it's xmas eve here?
lots of people don't work today here at least. 		[12:27]
RandalSchwartzit's just another work day for me.
stonehenge doesn't pay sick days or holidays. :)
or vacation 		[12:33]
................ (idle for 1h17mn)
***awyeah has quit IRC (Quit: ZNC - http://znc.in)
awyeah has joined #arpnetworks 		[13:50]
brycecThe life of the self-employed, eh? [13:59]
....... (idle for 32mn)
mercutioare you working christmas day too? [14:31]
http://updog.pw/ [14:38]
RandalSchwartzwell, part of it, yes.
as an atheist, christmas doesn't really mean much
except "lots of things closed needlessly" :) 		[14:41]
brycecI don't see why, as an atheist, you'd eschew a holiday and a joyful times. Sure, it has "Christ" in the name, but in this day and age that's pretty much the extent of religious value in Xmas
Why not celebrate yule and the winter harvest instead? :) 		[14:43]
RandalSchwartzMaybe festivus!
Oh crap, that's today! 		[14:44]
brycecAnd you got me nothing? You scoundrel! [14:45]
RandalSchwartzTime for the airing of grievances! [14:45]
brycecbrycec names his socks "grievance" [14:45]
RandalSchwartzwhich you wear on your feets of strength? :) [14:46]
bryceclol [14:46]
RandalSchwartzI'm not touching that with an aluminum pole. :) [14:47]
brycectwss [14:49]
BryceBotOkay! twss! 'I'm not touching that with an aluminum pole. :)' [14:49]
RandalSchwartzheh
usually it overtags
I wonder why it undertagged that one 		[14:50]
brycecWhat's really odd is that training the filter actually lowered the bayesian score. (0.92451488735822 -> 0.9150846827481) [14:51]
RandalSchwartzeven weirder
RandalSchwartz transfers from the sky club to the departure gate... 		[14:53]
.................... (idle for 1h39mn)
up_the_ironsmhoran: i didn't do anything [16:33]
qbit: interesting thread
"also the build bot server identifiers have the provider names in them and they get referenced and seen quite a lot"
qbit: ^^ what does he mean by that? I mean, who sees it?
qbit: remind me of the machine size you would need 		[16:38]
qbitnodejs nerds
dual cpu with 2g ram should work 		[16:39]
...... (idle for 26mn)
up_the_ironsi can probably swing that, but after the holidays. if it uses too much proc IO / disk, we'll have to talk about a different solution (maybe cheap dedi) [17:06]
bryceclol
Anyone that looks at the nodejs version, I guess...
But it's definitely less visible than, say, the hostname of the build machine in the system uname
^ which gets printed on boot, on login, etc 		[17:16]
up_the_ironsyeah [17:18]
brycec(In fact, it doesn't even print for node --version, so I have no idea where that "glory" is supposed to be seen)
But rest assured up_the_irons, you'll be FAMOUS 		[17:19]
up_the_ironsLOL
maybe the build server status is reported in some IRC / HipChat / Slack channel 		[17:19]
brycecAt my last job, it was very, very frequently told to us by [potential] customers that they're going to buy a hundred units a month (etc), and unsurprisingly they never really did. Consequently, I have become extraordinarily jaded when it comes to lines like that. [17:21]
acf_I wonder if the FreeBSD people would let you donate the use of a dedi as a build machine
like brycec was saying, those hostnames really do appear places 		[17:23]
brycecI'm under the impression that OpenBSD and FreeBSD are very well-equipped when comes to the x86 architectures. [17:23]
acf_the netbsd automatic build site is hosted from Columbia U
and has really crappy connectivity
at least NetBSD cross compiles everything. so it's all done on amd64 		[17:24]
brycec<obligatory desparaging remark about NetBSD> [17:25]
acf_:P [17:26]
brycecWhat you see as a strength, the OpenBSD project sees as a weakness re:cross-compiling. if an architecture cannot self-host, it's unsupported.
And I tend to agree 		[17:26]
acf_the problem is that everything takes forever to compile on vax [17:26]
brycecno argument there :p
But at least you don't have compiler issues 		[17:27]
acf_http://www.openbsd.org/images/rack2009.jpg
*all* the architectures 		[17:27]
up_the_ironsup_the_irons pets his vax machine [17:27]
brycec(as of 2009)
(things have changed since then, new ones, some retired, etc)
Also, that image is missing zaurus 		[17:27]
up_the_ironslol [17:29]
brycecoh shit, nevermind it's there
just tiny 		[17:29]
acf_mtr -4 vax.openbsd.org
I think I can ping the vax? 		[17:30]
brycecHA! There are two architectures I don't see in the photo (that would have been supported in 2009) - mac68k and m88k [17:35]
acf_maybe the use other 68k machines to build them? [17:37]
brycecWhat other 68k machines are in that photo?
(To be clear, I'm simply disproving "17:26:55 acf_ | *all* the architectures") 		[17:38]
acf_oh wow you're right
I wonder if there in some other place
or if they build them on qemu or something 		[17:38]
brycecoh wow you're right
twss 		[17:39]
BryceBotOkay! twss! 'oh wow you're right' [17:39]
brycecIf they can only build on qemu, then there's no reason to support the arch :p
I suspect those build machines are simply "elsewhere" 		[17:39]
............................................................................ (idle for 6h16mn)
mercutioopenbsd suppports 68k?
my amiga is so slow with unix
it reminds me of sun3s
i can't actually remember which i stick on it, it may have been old openbsd. openbsd doesn't support 68k anymore afaik at least not amiga
oh mac68k. 		[23:55]
↑back Search ←Prev date Next date→ Show only urls(Click on time to select a line by its url)