[00:35] *** Ehtyar has quit IRC (Quit: +++ OK ATH OK) [01:33] *** userZero has joined #arpnetworks [02:17] *** Ehtyar has joined #arpnetworks [02:46] *** fink has joined #arpnetworks [04:10] *** fink has quit IRC (Quit: fink) [05:01] *** dzup has quit IRC (Ping timeout: 268 seconds) [05:03] up_the_irons: lots of fun, it is a new toy for me!! [05:04] *** dzup has joined #arpnetworks [05:36] *** tdelborgo has joined #arpnetworks [05:39] *** tdelborgo has quit IRC (Client Quit) [05:51] *** tabthorpe is now known as abthorpet [05:57] *** tabthorpe has joined #arpnetworks [05:57] *** tabthorpe has quit IRC (Changing host) [05:57] *** tabthorpe has joined #arpnetworks [05:59] *** tabthorpe has quit IRC (Client Quit) [06:00] *** tabthorpe has joined #arpnetworks [06:00] *** tabthorpe has quit IRC (Changing host) [06:00] *** tabthorpe has joined #arpnetworks [06:01] *** tabthorpe has quit IRC (Client Quit) [06:02] *** tabthorpe has joined #arpnetworks [06:02] *** tabthorpe has quit IRC (Changing host) [06:02] *** tabthorpe has joined #arpnetworks [06:02] *** tabthorpe has quit IRC (Client Quit) [06:04] *** abthorpet has quit IRC (Quit: leaving) [06:06] *** tabthorpe has joined #arpnetworks [06:06] *** tabthorpe has quit IRC (Changing host) [06:06] *** tabthorpe has joined #arpnetworks [06:25] *** dzup has quit IRC (Ping timeout: 245 seconds) [06:31] *** heavysixer has joined #arpnetworks [06:31] *** ChanServ sets mode: +o heavysixer [06:37] *** dzup has joined #arpnetworks [07:01] *** dzup has quit IRC (Remote host closed the connection) [07:57] *** gcw|mbpro has quit IRC (Remote host closed the connection) [08:19] does the new beta system support newer libvirt that has the reboot option instead of shutdown/boot only? [08:23] *** gcw|mbpro has joined #arpnetworks [08:38] *** dzup has joined #arpnetworks [09:48] *** alexstanford has quit IRC (Ping timeout: 246 seconds) [09:48] *** nukefree has quit IRC (Ping timeout: 246 seconds) [09:48] *** alexstanford has joined #arpnetworks [09:48] *** nukefree has joined #arpnetworks [09:55] *** userZero has quit IRC (Remote host closed the connection) [09:56] *** userZero has joined #arpnetworks [10:00] That would be nice... feels very clunky not having a "reboot" option [10:09] *** gcw|mbpro has quit IRC (Remote host closed the connection) [10:11] *** HighJinx has quit IRC (Quit: Computer has gone to sleep.) [10:29] bryc3c: it was confirmed in the recent past that the libvirt in use by current production arpnetworks systems does not have that as an option. not an arpnetworks issue per se, I'm just expecting the new beta, having incorporating newer kvm and such would also have a newer libvirt that supports that [10:30] if you had a 'hard reboot' option you could keep your vnc connection as opposed to attempting to time it to still see the f* key sequence to boot off cdrom, for example ;-) [10:37] *** heavysixer has quit IRC (Ping timeout: 240 seconds) [10:37] *** heavysixer has joined #arpnetworks [10:37] *** ChanServ sets mode: +o heavysixer [10:44] *** heavysixer has quit IRC (Ping timeout: 260 seconds) [10:45] *** heavysixer has joined #arpnetworks [10:45] *** ChanServ sets mode: +o heavysixer [10:45] *** HighJinx has joined #arpnetworks [11:20] thanks toddf, I wasn't holding it against ARPNetworks [11:20] *** userZero has quit IRC (Remote host closed the connection) [11:20] And fwiw I find the "press F12" screen to last too long (about 5-10s) [11:34] *** gcw|mbpro has joined #arpnetworks [11:50] iirc it was a bios compile time option. not sure if a support@ request to have a faster timeout would result in any action but I'm sure they'll tell you if that is doable. [11:51] if the web ui and/or ssh ui were to permit specifying 'boot on cdrom' then the bios timeout would be moot and un-necessary [11:52] akin to 1and1's options on physical systems 'reboot into rescue image x' 'reboot into rescue image y' 'reboot' etc [11:52] done via tftp of course but anyway [12:04] up_the_irons: if i order a Power Up later on, will you grow the existing disk size or can it be a new block device presented to the vps? [12:05] ryk: growing existing disk is definately an option... will let up_the_irons answer on the new block device angle ;-) [12:18] ryk: RTFM :P http://support.arpnetworks.com/kb/vps/how-do-i-upgrade-or-downgrade-my-vps [12:19] *** heavysixer has quit IRC (Read error: Connection reset by peer) [12:20] (ryk is one of the many people I know from elsewhere. I'm not normally that mean) [12:20] yes you are [12:21] you are always a big meanie [12:21] *** heavysixer has joined #arpnetworks [12:21] *** ChanServ sets mode: +o heavysixer [12:21] ryk: there's a difference between being a fair op, and a meanie [12:21] /kick ryk [12:21] damnit [12:41] ryk: yep, we can do either. tnx bryc3c for the link [12:43] bryc3c: the timeout was increased since there were so many complaints it was too short [12:44] up_the_irons: Yeah I'm not complaining... 'tis just my opinion. But how often am I rebooting my VPS? :P [12:55] up_the_irons: by the way, a long time ago we talked about backup [12:56] i happened to call rootbsd before i placed this order, because they're pretty local to me [12:56] they just have a bug storage box with chrooted homedir's that everyone can ssh to [12:56] *big [13:00] *** HighJinx has quit IRC (Ping timeout: 255 seconds) [13:03] *** HighJinx has joined #arpnetworks [13:05] *** alexstanford has quit IRC (Ping timeout: 246 seconds) [13:05] *** gcw|mbpro has quit IRC (Remote host closed the connection) [13:08] *** alexstanford has joined #arpnetworks [13:15] *** alexstanford has quit IRC (Ping timeout: 246 seconds) [13:15] *** alexstanford has joined #arpnetworks [13:19] *** sako has joined #arpnetworks [13:19] *** sako has quit IRC (Changing host) [13:19] *** sako has joined #arpnetworks [13:23] somehow I recall prices listed with ram/bandwidth/disk increases somewhere. perhaps that was before the website remake. also I understand cpu count is a commodity that can be increased with appropriate funding as well. if one is updating $random_info_page one should add it also. Just my $.02 [13:26] toddf: when you click learn more on the right side you can see VPS powerups on the left side [13:27] whoa... it's true [13:27] I totally hadn't noticed that before [13:28] daca: there it is indeed ;-) [13:28] still it lacks cpu bits. maybe thats a non advertised feature I recall seeing discussed eyons ago... [13:29] It's in the FAQ but no pricing [13:38] i thought cpu share is assigned proportationally to memory % usage [13:38] at least, that is standard practice. [13:38] I'm not talking about cpu share, you get 1 dedicated cpu per vps [13:38] well not memory usage, but how much RAM is assigned. [13:38] I'm talking about multiple cpus per vps [13:39] who gets 1 dedicated cpu per vpus? [13:40] see "Dedicated CPU resources" on the arpnetworks.com/vps page [13:41] i doubt anyone even gets a dedicated core, excpet for maybe the biggest plan [13:41] ryk: it's about thread/process concurrency. Same as having a single/dual core CPU in your desktop. With just the single core, we get 1 thread at a time basiucally [13:41] if only 8 cores per host [13:41] what do you think that means? [13:41] I've always been amazed by the cpu my small vps has. 'md5 -t' for example beats any real system I have in my office by quite a bit. [13:42] i don't know what it means, but the economics of a box hosting 8 vps's @ $10/mo each with their own dedicated core does not work. [13:42] how about mixing small vps's with bigger vps's ? [13:44] i would be willing to bet that it means that CPU share is not oversubscribed in terms of GHz [13:44] i.e., a small VPS gets 1 core at 1GHz [13:44] a 3GHz xeon can server 3 vps's on a single core, in that case [13:45] up_the_irons: care to enlighten us on what 'Dedicated CPU resources' means? [13:45] toddf: you could just be on a host with friendly neighbors, and are able to consume available cpu that they're not using. [13:46] hmm, where'd the 'fbi' bit go that was logging this channel? at one point I could have sworn it existed and was making some parts publically searchable [13:46] there is a logs page [13:46] lets see if my own logging of this channel produces any jewels based on that phrase [13:47] http://irclogger.arpnetworks.com/irclogger_logs/arpnetworks [13:47] it hasn't come up since 2010 with that exact phrase, odd [14:15] *** gcw|mbpro has joined #arpnetworks [14:17] *** gcw|mbpro has quit IRC (Remote host closed the connection) [14:17] *** gcw|mbpro has joined #arpnetworks [14:20] *** Ehtyar has quit IRC (Quit: I was raided by the FBI and all I got to keep was this lousy quit message!) [14:34] todd: i wonder if you're on a newer cpu than me [14:35] ryk: i think it's just that you only get one core [14:35] it's still shared [14:35] but it means less context switches [14:36] which means most consistent performance [14:37] err more [14:37] it does seem a bit strange not getting like 2 or something on bigger plans though [14:40] ^ [14:41] vmware used to say that SMP vms were inefficient [14:42] since you had to lock 2+ CPUs instead of just 1. [14:42] vmware used to say that 64 bit vms were inefficient [14:42] well it depends [14:42] virtualisation extensions help to some degree [14:42] the newer cpus got faster and faster [14:43] err at doing switches [14:43] it also copmletely depends on how high your cpu load is [14:43] like if you're usually at max 60% cpu [14:43] sure, on an idle machine it doesn't matter. [14:43] these aren't idle ;) [14:43] then everyone having 2 cpu cores wouldn't relaly matter [14:43] and would be faster for individual vms [14:43] but if you're regularly at 100% load [14:44] i imagine a lot of the cpu load comes from qemu [14:44] as well [14:44] as things like openbsd aren't using virtual drivers [14:45] ithink they're 8 core [14:45] so if 4 people are using 100% cpu [14:45] and have 1 cpu core [14:46] then 2 cpu cores are going hard on qemu-dm etc [14:46] *** heavysixer has quit IRC (Read error: Connection reset by peer) [14:46] the 2 cpu cores doing "this and that" [14:46] then it'd be full load [14:46] but i doubt there's "400% cpu" much [14:46] err 4 people using 100% cpu [14:47] i wouldn't use 100% cpu for more than like 5 minutes [14:49] *** heavysixer has joined #arpnetworks [14:49] *** ChanServ sets mode: +o heavysixer [14:55] *** bryc3c is now known as _brycec [14:56] *** _brycec is now known as octothorpe [14:56] *** octothorpe is now known as bryc3c [15:10] anyway i haven't had cpu probs [15:18] I've heard little about cpu contention here. what I have heard about is disk io contention. if you're hammering the disk consistently for a long period of time not just normal activity but like doing a dd to/from disk constantly, don't expect to be treated kindly by fellow customers on the same host system .. ;-) [15:19] * jdoe will string you up by the balls. [15:19] if you doing have balls, I'll have them surgically attached, THEN string you up by them. [15:30] heh [15:30] my disk i/o is reasonably steady slow with no virtio [15:30] it hasn't got extremely bad ever that i recall? [15:34] jdoe: could you attach an extra set, then string me up by those instead? [15:35] I'm... quite attached HAHAHAHAH to my current set. [15:45] *** sako has quit IRC (Ping timeout: 240 seconds) [15:47] *** sako has joined #arpnetworks [16:10] *** Ehtyar has joined #arpnetworks [16:41] *** sako has quit IRC (Ping timeout: 260 seconds) [18:53] *** HighJinx has quit IRC (Quit: Computer has gone to sleep.) [19:19] *** gcw|mbpro has quit IRC (Remote host closed the connection) [19:30] *** gcw|mbpro has joined #arpnetworks [19:46] *** HighJinx has joined #arpnetworks [20:01] *** gcw|mbpro is now known as gcw|mbpro|away [21:05] *** sako has joined #arpnetworks [21:32] *** sako_ has joined #arpnetworks [21:32] *** sako has quit IRC (Ping timeout: 248 seconds) [21:54] *** gcw|mbpro|away is now known as gcw|MBPro [22:52] *** sako_ has quit IRC (Ping timeout: 260 seconds) [22:59] up_the_irons: http://www.abthorpe.org/2012/10/abthorpe-org-is-back/ [23:06] :o