#arpnetworks 2014-12-23,Tue

↑back Search ←Prev date Next date→ Show only urls

(Click on time to select a line by its url)

Who	What	When
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_irons	ah i c	[00:38]
mercutio	is 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]
mercutio	cool. it was kind of disturbing that happened for so long	[00:47]
BryceBot	That's what she said!!	[00:47]
acf_	yea	[00:47]
mercutio	well not as disturbing as comcast..	[00:48]
acf_	it was replaced with Amazon EC2 -> Verizon congestion :P	[00:48]
mercutio	err 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]
mercutio	i 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]
mercutio	what'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]
mercutio	congestion is such a complicated issue netflix kind of hilighted it.	[00:50]
BryceBot	That's what she said!!	[00:51]
mercutio	but 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]
mercutio	but at&t, verizon, comcast etc are all evil	[00:52]
acf_	also they still don't IPv6 peer with HE	[00:52]
mercutio	it'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]
mercutio	it'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]
mercutio	but who's to know how much the traffic hurt their network internally	[00:54]
acf_	Comcast's network?	[00:54]
mercutio	i 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]
mercutio	the 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]
BryceBot	That'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]
mercutio	probably 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]
mercutio	i 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]
mercutio	well 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]
mercutio	for carrying traffic sure	[00:59]
acf_	it follows the "sender pays" model we've always had	[00:59]
mercutio	like 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]
mercutio	or 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]
mercutio	well 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]
mercutio	but 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]
mercutio	not 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]
mercutio	but 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]
mercutio	and 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]
mercutio	distance 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]
mercutio	like 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]
BryceBot	That's what she said!!	[01:10]
mercutio	it's not so reasonable to dump lots of traffic in kansas or such.	[01:10]
acf_	oh yes	[01:10]
mercutio	because 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]
mercutio	kanasas 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]
mercutio	well 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]
mercutio	some 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]
mercutio	so santa maria is the nearest location?	[01:13]
acf_	yea	[01:13]
mercutio	so santa maria looks like somewhere an interconnect should happen	[01:14]
acf_	how would that happen? there is no datacenter or anthing...	[01:14]
mercutio	hmm 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]
mercutio	here it happens in telephone exchanges.	[01:14]
BryceBot	That'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]
mercutio	dsl 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]
mercutio	http://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]
mercutio	verizon 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]
mercutio	so 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]
mercutio	but yeah ok ideally they should be terminating on bng's closer. where is SLO?	[01:17]
acf_	bng?	[01:17]
mercutio	pppoe termination or ppp as well as dhcp etc.	[01:18]
acf_	40 miles from here opposite direction of LA though	[01:18]
mercutio	http://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]
mercutio	is there other providers other than verizon?	[01:19]
acf_	AT&T	[01:19]
mercutio	so verizon and at&t should peer there too.	[01:19]
acf_	but I believe that datacenter leases lines to LAX and SJC	[01:19]
mercutio	and 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]
mercutio	and 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]
mercutio	and 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]
mercutio	it'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]
mercutio	if 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]
mercutio	but 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]
mercutio	hmm 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]
mercutio	netflix'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]
mercutio	yeah 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]
mercutio	so 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]
mercutio	new zealand has actually got quite good peering in general. and the US has quite bad peering :)	[01:31]
acf_	yea	[01:31]
mercutio	although 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]
mercutio	yeah. 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]
mercutio	and 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]
mercutio	but 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]
mercutio	they probably have dslams there anyway?	[01:34]
acf_	they do	[01:34]
mercutio	so 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]
mercutio	apparently 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]
mercutio	at 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]
mercutio	hard 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]
mercutio	this 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]
mercutio	oh is it you i have been smokepinging for ages?	[01:40]
acf_	idk. my IP probably has changed :P	[01:41]
mercutio	herh 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]
mercutio	hmm snloca	[01:41]
acf_	formerly my Verizon IP	[01:42]
mercutio	cool.	[01:42]
acf_	snloca == San Luis Obispo	[01:42]
mercutio	yeah. 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]
mercutio	why wouldn't they?	[01:47]
acf_	"not supported"	[01:48]
mercutio	lame is it vdsl or adsl?	[01:48]
acf_	adsl	[01:48]
mercutio	no excuses then :) does vdsl have the same interlaving?	[01:49]
acf_	they don't offer vdsl here	[01:49]
mercutio	and 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]
mercutio	that 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]
mercutio	but 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]
mercutio	oh you can't see your modem stats.	[01:50]
acf_	I think it's fixed here	[01:50]
mercutio	i've been snr tweaking adsl for years.	[01:51]
acf_	most people here have a modem with integrated router. I don't	[01:51]
mercutio	normal 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]
mercutio	on 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]
mercutio	it's like the lower the better	[01:52]
acf_	adjusting tx power?	[01:52]
mercutio	unless 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]
mercutio	with no interleaving.	[01:55]
acf_	adjusting "training margin" enables faster line rates what kind of latency do you get?	[01:55]
mercutio	yeh. 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]
mercutio	i want lower :)	[01:56]
acf_	I get 8 ms on DOCSIS	[01:56]
mercutio	i 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]
mercutio	it's the jitter that hurts with docsis though	[01:57]
acf_	just to the local node	[01:57]
mercutio	that seems high.	[01:57]
acf_	ummm...	[01:58]
mercutio	also my vdsl is screwed atm because i have bad wiring	[01:58]
acf_	"Cable Modem Status Offline"	[01:58]
mercutio	and it added 8 msec interleaving downstream :( after fixing cable.	[01:58]
acf_	looks like DOCSIS 3	[01:58]
mercutio	docsis3 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]
mercutio	you have two lines?	[02:00]
acf_	Verizon and Comcast my Verizon line is cheap, and bundled with phone but it sucks	[02:00]
mercutio	so 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]
mercutio	heh 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]
mercutio	then 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]
BryceBot	That's what she said!!	[02:03]
mercutio	then 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]
mercutio	yeah 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]
mercutio	but 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]
mercutio	like 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]
mercutio	yeah. 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]
mercutio	and 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)
qbit	up_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]
mhoran	up_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)
mercutio	mhoran: i wouldn't be surprised if it's time of day related.	[11:14]
mhoran	Slower now, but not as slow as last night / last time we looked into it.	[11:15]
.......... (idle for 45mn)
mercutio	well 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)
brycec	Where in the world is it already xmas??? 11:59:49 mercutio \| well it is xmas.	[12:27]
mercutio	it's "xmas period" it's xmas eve here? lots of people don't work today here at least.	[12:27]
RandalSchwartz	it'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]
brycec	The life of the self-employed, eh?	[13:59]
....... (idle for 32mn)
mercutio	are you working christmas day too?	[14:31]
	http://updog.pw/	[14:38]
RandalSchwartz	well, part of it, yes. as an atheist, christmas doesn't really mean much except "lots of things closed needlessly" :)	[14:41]
brycec	I 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]
RandalSchwartz	Maybe festivus! Oh crap, that's today!	[14:44]
brycec	And you got me nothing? You scoundrel!	[14:45]
RandalSchwartz	Time for the airing of grievances!	[14:45]
brycec	brycec names his socks "grievance"	[14:45]
RandalSchwartz	which you wear on your feets of strength? :)	[14:46]
brycec	lol	[14:46]
RandalSchwartz	I'm not touching that with an aluminum pole. :)	[14:47]
brycec	twss	[14:49]
BryceBot	Okay! twss! 'I'm not touching that with an aluminum pole. :)'	[14:49]
RandalSchwartz	heh usually it overtags I wonder why it undertagged that one	[14:50]
brycec	What's really odd is that training the filter actually lowered the bayesian score. (0.92451488735822 -> 0.9150846827481)	[14:51]
RandalSchwartz	even weirder RandalSchwartz transfers from the sky club to the departure gate...	[14:53]
.................... (idle for 1h39mn)
up_the_irons	mhoran: 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]
qbit	nodejs nerds dual cpu with 2g ram should work	[16:39]
...... (idle for 26mn)
up_the_irons	i 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]
brycec	lol 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_irons	yeah	[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_irons	LOL maybe the build server status is reported in some IRC / HipChat / Slack channel	[17:19]
brycec	At 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]
brycec	I'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]
brycec	What 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]
brycec	no 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_irons	up_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_irons	lol	[17:29]
brycec	oh shit, nevermind it's there just tiny	[17:29]
acf_	mtr -4 vax.openbsd.org I think I can ping the vax?	[17:30]
brycec	HA! 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]
brycec	What 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]
brycec	oh wow you're right twss	[17:39]
BryceBot	Okay! twss! 'oh wow you're right'	[17:39]
brycec	If 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)
mercutio	openbsd 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)