Re: tor inside vmm, horribly slow?!
> Am 14.02.2018 um 02:09 schrieb Chris Cappuccio : > > Revert uipc_socket.c rev 1.90. Does tor work properly again? Because of https://marc.info/?l=openbsd-ports&m=151855574502582 I tried a newer snapshot and now tor works properly again. signature.asc Description: Message signed with OpenPGP
Re: tor inside vmm, horribly slow?!
Oops, actually uipc_socket2.c
Re: tor inside vmm, horribly slow?!
Revert uipc_socket.c rev 1.90. Does tor work properly again? Thomas Weinbrenner [m...@tweinbrenner.net] wrote: > > > > Am 12.02.2018 um 00:38 schrieb Jiri B : > > > > Hi, > > > > has anybody tried to run tor inside vmm guest? > > > > it's horrible slow, just doing 'tor-resolve $dnsname' takes > > sometimes ages. > > Perhaps this has nothing to do with vmm. > > I am not a computer expert, just a normal user (so please don't ask me > to difficult questions), but I run tor on my computer at home (so it's > real hardware and no vmm). > > Since upgrading OpenBSD from > > | OpenBSD 6.2-current (GENERIC.MP) #399: Fri Feb 2 18:28:58 MST 2018 > |dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > to > > | OpenBSD 6.2-current (GENERIC.MP) #4: Sat Feb 10 18:04:19 MST 2018 > |dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > my tor server also has problems. > > > /var/log/daemon: > | Feb 11 20:15:50 server Tor[54286]: Your system clock just jumped 115 > seconds forward; assuming established circuits no longer work. > | Feb 11 20:16:02 server Tor[54286]: Tor has successfully opened a circuit. > Looks like client functionality is working. > | Feb 11 20:16:02 server Tor[54286]: Tor has successfully opened a circuit. > Looks like client functionality is working. > | Feb 11 20:24:43 server Tor[54286]: Your system clock just jumped 299 > seconds forward; assuming established circuits no longer work. > | Feb 11 20:26:24 server Tor[54286]: tor_assertion_failed_: Bug: > src/or/channel.c:1503: channel_closed: Assertion CHANNEL_CONDEMNED(chan) > failed; aborting. (on Tor 0.3.2.9 9e8b762fcecfece6) > | Feb 11 20:26:24 server Tor[54286]: Bug: Assertion CHANNEL_CONDEMNED(chan) > failed in channel_closed at src/or/channel.c:1503. (Stack trace not > available) (on Tor 0.3.2.9 9e8b762fcecfece6) > > dmesg: > > OpenBSD 6.2-current (GENERIC.MP) #4: Sat Feb 10 18:04:19 MST 2018 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 8351621120 (7964MB) > avail mem = 8091496448 (7716MB) > enter_shared_special_pages: entered idt page va 0x8001 pa > 0x1d5c000 > enter_shared_special_pages: entered kutext page va 0x81833000 pa > 0x1833000 > enter_shared_special_pages: entered kutext page va 0x81834000 pa > 0x1834000 > enter_shared_special_pages: entered kutext page va 0x81835000 pa > 0x1835000 > enter_shared_special_pages: entered kudata page va 0x81acb000 pa > 0x1acb000 > cpu_enter_pages: entered tss+gdt page at va 0x81aa2000 pa 0x1aa2000 > cpu_enter_pages: entered t.stack page at va 0x81aa3000 pa 0x1aa3000 > cpu_enter_pages: cif_tss.tss_rsp0 = 0x81aa33e0 > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xedc10 (87 entries) > bios0: vendor LENOVO version "FBKTCQAUS" date 12/16/2017 > bios0: LENOVO ThinkServer TS140 > acpi0 at bios0: rev 2 > acpi0: sleep states S0 S5 > acpi0: tables DSDT FACP APIC FPDT FIDT TCPA DBGP LUFT SSDT SSDT MCFG > HPET SSDT SSDT ASF! DMAR EINJ ERST HEST BERT BGRT > acpi0: wakeup devices UAR1(S0) PXSX(S0) RP01(S0) PXSX(S0) PXSX(S0) > PXSX(S0) RP04(S0) PXSX(S0) PXSX(S0) PXSX(S0) PXSX(S0) GLAN(S0) > EHC1(S0) EHC2(S0) XHC_(S0) HDEF(S0) [...] > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > lapic_map: entered lapic page va 0x81aa6000 pa 0xfee0 > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Xeon(R) CPU E3-1226 v3 @ 3.30GHz, 3492.47 MHz > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN > cpu0: 256KB 64b/line 8-way L2 cache > acpitimer0: recalibrated TSC frequency 3292379149 Hz > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges > cpu0: apic clock running at 99MHz > cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4, IBE > cpu1 at mainbus0cpu_enter_pages: entered tss+gdt page at va > 0x80002200 pa 0x10f184000 > cpu_enter_pages: entered t.stack page at va 0x800022001000 pa 0x10f185000 > cpu_enter_pages: cif_tss.tss_rsp0 = 0x8000220013e0 > : apid 2 (application processor) > cpu1: Intel(R) Xeon(R) CPU E3-1226 v3 @ 3.30GHz, 3491.92 MHz > cpu1: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,SEN
Re: tor inside vmm, horribly slow?!
> Am 12.02.2018 um 00:38 schrieb Jiri B : > > Hi, > > has anybody tried to run tor inside vmm guest? > > it's horrible slow, just doing 'tor-resolve $dnsname' takes > sometimes ages. Perhaps this has nothing to do with vmm. I am not a computer expert, just a normal user (so please don't ask me to difficult questions), but I run tor on my computer at home (so it's real hardware and no vmm). Since upgrading OpenBSD from | OpenBSD 6.2-current (GENERIC.MP) #399: Fri Feb 2 18:28:58 MST 2018 |dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP to | OpenBSD 6.2-current (GENERIC.MP) #4: Sat Feb 10 18:04:19 MST 2018 |dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP my tor server also has problems. /var/log/daemon: | Feb 11 20:15:50 server Tor[54286]: Your system clock just jumped 115 seconds forward; assuming established circuits no longer work. | Feb 11 20:16:02 server Tor[54286]: Tor has successfully opened a circuit. Looks like client functionality is working. | Feb 11 20:16:02 server Tor[54286]: Tor has successfully opened a circuit. Looks like client functionality is working. | Feb 11 20:24:43 server Tor[54286]: Your system clock just jumped 299 seconds forward; assuming established circuits no longer work. | Feb 11 20:26:24 server Tor[54286]: tor_assertion_failed_: Bug: src/or/channel.c:1503: channel_closed: Assertion CHANNEL_CONDEMNED(chan) failed; aborting. (on Tor 0.3.2.9 9e8b762fcecfece6) | Feb 11 20:26:24 server Tor[54286]: Bug: Assertion CHANNEL_CONDEMNED(chan) failed in channel_closed at src/or/channel.c:1503. (Stack trace not available) (on Tor 0.3.2.9 9e8b762fcecfece6) dmesg: OpenBSD 6.2-current (GENERIC.MP) #4: Sat Feb 10 18:04:19 MST 2018 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8351621120 (7964MB) avail mem = 8091496448 (7716MB) enter_shared_special_pages: entered idt page va 0x8001 pa 0x1d5c000 enter_shared_special_pages: entered kutext page va 0x81833000 pa 0x1833000 enter_shared_special_pages: entered kutext page va 0x81834000 pa 0x1834000 enter_shared_special_pages: entered kutext page va 0x81835000 pa 0x1835000 enter_shared_special_pages: entered kudata page va 0x81acb000 pa 0x1acb000 cpu_enter_pages: entered tss+gdt page at va 0x81aa2000 pa 0x1aa2000 cpu_enter_pages: entered t.stack page at va 0x81aa3000 pa 0x1aa3000 cpu_enter_pages: cif_tss.tss_rsp0 = 0x81aa33e0 mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xedc10 (87 entries) bios0: vendor LENOVO version "FBKTCQAUS" date 12/16/2017 bios0: LENOVO ThinkServer TS140 acpi0 at bios0: rev 2 acpi0: sleep states S0 S5 acpi0: tables DSDT FACP APIC FPDT FIDT TCPA DBGP LUFT SSDT SSDT MCFG HPET SSDT SSDT ASF! DMAR EINJ ERST HEST BERT BGRT acpi0: wakeup devices UAR1(S0) PXSX(S0) RP01(S0) PXSX(S0) PXSX(S0) PXSX(S0) RP04(S0) PXSX(S0) PXSX(S0) PXSX(S0) PXSX(S0) GLAN(S0) EHC1(S0) EHC2(S0) XHC_(S0) HDEF(S0) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat lapic_map: entered lapic page va 0x81aa6000 pa 0xfee0 cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU E3-1226 v3 @ 3.30GHz, 3492.47 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache acpitimer0: recalibrated TSC frequency 3292379149 Hz cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4, IBE cpu1 at mainbus0cpu_enter_pages: entered tss+gdt page at va 0x80002200 pa 0x10f184000 cpu_enter_pages: entered t.stack page at va 0x800022001000 pa 0x10f185000 cpu_enter_pages: cif_tss.tss_rsp0 = 0x8000220013e0 : apid 2 (application processor) cpu1: Intel(R) Xeon(R) CPU E3-1226 v3 @ 3.30GHz, 3491.92 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0cpu_enter_pages: entered tss+gdt page at va 0x800022011000 pa 0x10f18f000 cpu_enter_pages: entered t.stack page at va 0x800022012000 pa 0x10f19 cpu_enter_pages: cif_tss.tss_rsp0 = 0x8000220123e0
Re: tor inside vmm, horribly slow?!
On Mon, Feb 12, 2018 at 12:38:00AM -0800, Mike Larkin wrote: > > > > it's horrible slow, just doing 'tor-resolve $dnsname' takes > > > > sometimes ages. > > > > [...] > [...] > > What did the guest pick for timecounter? (sysctl kern.timecounter.hardware) > > Your hardware is nearly a decade old. I wouldn't be surprised if vmm > picked some ancient timecounter hardware. For the example below, my guest > chose 'tsc' (I have a 2013-era Ivy Bridge CPU). All my hosts/VMs are > -current. And we know if your hardware is shit, we do the best we can but > no promises as to how precise time is going to be. With tsc timecounter, > my VMs that have been up for weeks have drifted maybe a second or two from > the host. > > [...] > > In other words, I don't see anything odd here. The vm appears to actually > be running faster than the host. I'm not concerned about the 2-3 second > difference on the first resolve. I bet if I ran it a hundred times I'd see > things pretty much the same. Mike, thank you for your time. The VM picked 'tsc' as timecounter. Putting CC Pascal, Tor port maintainer, as I am suspicious that this slowness is related to what tor itself is doing in that time. Pascal, any idea what could cause slowness of tor when using onion service inside VMM? Info below (plus history https://marc.info/?l=openbsd-misc&m=151839235419514&w=2): Feb 12 10:30:25 onion Tor[96278]: connection_connect_sockaddr: Connection to socket established (sock 4). Feb 12 10:32:55 onion Tor[96278]: connection_edge_reached_eof: conn (fd 4) reached eof. Closing. Feb 12 10:32:55 onion Tor[96278]: Your system clock just jumped 151 seconds forward; assuming established circuits no longer work. ^^^ 2 mins gap? Tor tests, if this is general issue or not. - scenario 1 * loop date + tor-resolve $dnsname + sleep 1 * torsocks curl -s -I http://www.openbsd.org ^^ this works ok - scenario 2 make tor to have local onion service with httpd enabled * install -d -o _tor -g _tor -m 700 /var/tor/onion * modify /etc/tor/torrc: Log debug syslog HiddenServiceDir /var/tor/onion/ HiddenServicePort 80 127.0.0.1:80 * enable httpd & tor * loop date + tor-resolve $dnsname + sleep 1 * get your .onion service address cat /var/tor/onion/hostname * access your .onion service from other (tor)browser ... Feb 12 10:30:24.519 [warn] Got SOCKS5 status response '4': host is unreachable Mon Feb 12 10:30:26 CET 2018 129.128.5.194 Mon Feb 12 10:32:58 CET 2018 129.128.5.194 Mon Feb 12 10:33:00 CET 2018 ... ^^ tor-resolve $dnsnanme gets slow downed in a while, 2 mins gap Feb 12 10:30:24 onion Tor[96278]: rend_service_rendezvous_has_opened: Done building circuit 2327426966 to rendezvous with cookie D92E6387 for service Feb 12 10:30:24 onion Tor[96278]: internal circ (length 4): $0FBE018DADAB416DE17A10C5D4AD3EBF0E243561(open) $BF50E09EED25B82861CF95E1AAA42DCFEF53E5D1(open) $F80FDE27EFCB3F6A7B4E2CC517133DBFFA78BA2D(open) $CCF0E904BAD135F6B2180BD89D19E487F83786A5(open) Feb 12 10:30:24 onion Tor[96278]: connection_handle_listener_read: New SOCKS connection opened from 127.0.0.1. Feb 12 10:30:24 onion Tor[96278]: rep_hist_note_used_port: New port prediction added. Will continue predictive circ building for 1967 more seconds. Feb 12 10:30:24 onion Tor[96278]: connection_edge_process_inbuf: data from edge while in 'waiting for circuit' state. Leaving it on buffer. Feb 12 10:30:24 onion Tor[96278]: exit circ (length 3): $0FBE018DADAB416DE17A10C5D4AD3EBF0E243561(open) $594252BFEE13625AC120F50F3015CB3C1DA55690(open) $1AF72E8906E6C49481A791A6F8F84F8DFEBBB2BA(open) Feb 12 10:30:24 onion Tor[96278]: pathbias_count_use_attempt: Used circuit 2 is already in path state use succeeded. Circuit is a General-purpose client currently open. Feb 12 10:30:24 onion Tor[96278]: link_apconn_to_circ: Looks like completed circuit to [scrubbed] does allow optimistic data for connection to [scrubbed] Feb 12 10:30:24 onion Tor[96278]: connection_ap_handshake_send_resolve: Address sent for resolve, ap socket 4, n_circ_id 2260876578 Feb 12 10:30:25 onion Tor[96278]: connection_connect_sockaddr: Connection to socket established (sock 4). Feb 12 10:32:55 onion Tor[96278]: connection_edge_reached_eof: conn (fd 4) reached eof. Closing. Feb 12 10:32:55 onion Tor[96278]: Your system clock just jumped 151 seconds forward; assuming established circuits no longer work. ^^ 2 mins gap So just slow HW issue? Jiri
Re: tor inside vmm, horribly slow?!
On Mon, Feb 12, 2018 at 03:07:31AM -0500, Jiri B wrote:
> On Sun, Feb 11, 2018 at 04:47:02PM -0800, Mike Larkin wrote:
> > > has anybody tried to run tor inside vmm guest?
> > >
> > > it's horrible slow, just doing 'tor-resolve $dnsname' takes
> > > sometimes ages.
> > > [...]
> > > is it related to vmm ssl issue reported in the past?
> >
> > no
> >
> > > [...]
> > This report sucks. no dmesg, no information about what the VM config is,
> > what
> > version the guest is, what version the host is, etc.
>
> Big apologize, I thought it could be something known.
> Info below. Thank you for help.
>
> Jiri
>
What did the guest pick for timecounter? (sysctl kern.timecounter.hardware)
Your hardware is nearly a decade old. I wouldn't be surprised if vmm
picked some ancient timecounter hardware. For the example below, my guest
chose 'tsc' (I have a 2013-era Ivy Bridge CPU). All my hosts/VMs are
-current. And we know if your hardware is shit, we do the best we can but
no promises as to how precise time is going to be. With tsc timecounter,
my VMs that have been up for weeks have drifted maybe a second or two from
the host.
In any case, in my amd64 VM, the first time I do your command I see this:
time tor-resolve www.openbsd.org
129.128.5.194
0m20.30s real 0m00.00s user 0m00.00s system
And the second time:
time tor-resolve www.openbsd.org
129.128.5.194
0m00.20s real 0m00.00s user 0m00.00s system
Now, on the host, the first time:
time tor-resolve www.openbsd.org
129.128.5.194
0m17.54s real 0m00.00s user 0m00.01s system
And the second time on the host:
time tor-resolve www.openbsd.org
129.128.5.194
0m00.54s real 0m00.00s user 0m00.02s system
In other words, I don't see anything odd here. The vm appears to actually
be running faster than the host. I'm not concerned about the 2-3 second
difference on the first resolve. I bet if I ran it a hundred times I'd see
things pretty much the same.
-ml
> Another try inside vmm guest:
> ~
>
> # time tor-resolve www.openbsd.org
> 129.128.5.194
> 0m00.14s real 0m00.00s user 0m00.00s system
> # time tor-resolve www.openbsd.org
> 129.128.5.194
> 0m52.96s real 0m00.00s user 0m00.00s system
>
> # tail /var/log/daemon
> Feb 12 08:19:59 onion Tor[21861]: Bootstrapped 100%: Done
> Feb 12 08:20:04 onion ntpd[51629]: adjusting local clock by 0.384653s
> Feb 12 08:23:01 onion ntpd[51629]: adjusting local clock by -0.063873s
> Feb 12 08:42:58 onion Tor[21861]: Your system clock just jumped 150 seconds
> forward; assuming established circuits no longer work.
> Feb 12 08:42:59 onion Tor[21861]: Tor has successfully opened a circuit.
> Looks like client functionality is working.
> Feb 12 08:42:59 onion Tor[21861]: Tor has successfully opened a circuit.
> Looks like client functionality is working.
> Feb 12 08:45:55 onion Tor[21861]: Your system clock just jumped 150 seconds
> forward; assuming established circuits no longer work.
> Feb 12 08:45:57 onion Tor[21861]: Tor has successfully opened a circuit.
> Looks like client functionality is working.
> Feb 12 08:45:57 onion Tor[21861]: Tor has successfully opened a circuit.
> Looks like client functionality is working.
> Feb 12 08:47:05 onion ntpd[51629]: adjusting clock frequency by -7.934969 to
> -23.542969ppm
>
> VMM:
>
>
> (Originally I forgot 'group internal' in vm.conf, so I put tap1 into group
> 'internal' manually via ifconfig.)
>
> vm "onion" {
> disable
> owner jirib
> memory 512M
> boot $kernel
> local interface tap
> disk $onion_osdisk
> disk $onion_datadisk
> }
>
> Networking on host:
> ~~~
>
> # route -nv show -inet | grep ^default
> default176.74.xxx.xxx UGS538658 - 8 em0
> "internet4"
>
> # sysctl net.inet.ip.forwarding
>
>
> net.inet.ip.forwarding=1
>
> em0: flags=8843 mtu 1500
> lladdr 90:e2:ba:xx:xx:xx
> index 1 priority 0 llprio 3
> groups: public egress
> media: Ethernet autoselect (100baseTX full-duplex,rxpause,txpause)
> status: active
> inet 176.74.xxx netmask 0xffe0 broadcast 176.74.xxx
>
> tap1: flags=8843 mtu 1500
> lladdr fe:e1:ba:d2:f7:28
> description: vm2-if0-onion
> index 17 priority 0 llprio 3
> groups: tap internal
> status: active
> inet 100.64.2.2 netmask 0xfffe
>
> PF on host (uses 'group internal'):
> ~~~
>
> # pfctl -sr | egrep '(on egress.*nat-to|on internal.*all)'
> pass out quick on egress from any to route "internet4" flags S/SA nat-to
> (egress) round-robin
> pass in quick on internal all flags S/SA
>
> Storage on host:
>
>
Re: tor inside vmm, horribly slow?!
On Sun, Feb 11, 2018 at 04:47:02PM -0800, Mike Larkin wrote:
> > has anybody tried to run tor inside vmm guest?
> >
> > it's horrible slow, just doing 'tor-resolve $dnsname' takes
> > sometimes ages.
> > [...]
> > is it related to vmm ssl issue reported in the past?
>
> no
>
> > [...]
> This report sucks. no dmesg, no information about what the VM config is, what
> version the guest is, what version the host is, etc.
Big apologize, I thought it could be something known.
Info below. Thank you for help.
Jiri
Another try inside vmm guest:
~
# time tor-resolve www.openbsd.org
129.128.5.194
0m00.14s real 0m00.00s user 0m00.00s system
# time tor-resolve www.openbsd.org
129.128.5.194
0m52.96s real 0m00.00s user 0m00.00s system
# tail /var/log/daemon
Feb 12 08:19:59 onion Tor[21861]: Bootstrapped 100%: Done
Feb 12 08:20:04 onion ntpd[51629]: adjusting local clock by 0.384653s
Feb 12 08:23:01 onion ntpd[51629]: adjusting local clock by -0.063873s
Feb 12 08:42:58 onion Tor[21861]: Your system clock just jumped 150 seconds
forward; assuming established circuits no longer work.
Feb 12 08:42:59 onion Tor[21861]: Tor has successfully opened a circuit. Looks
like client functionality is working.
Feb 12 08:42:59 onion Tor[21861]: Tor has successfully opened a circuit. Looks
like client functionality is working.
Feb 12 08:45:55 onion Tor[21861]: Your system clock just jumped 150 seconds
forward; assuming established circuits no longer work.
Feb 12 08:45:57 onion Tor[21861]: Tor has successfully opened a circuit. Looks
like client functionality is working.
Feb 12 08:45:57 onion Tor[21861]: Tor has successfully opened a circuit. Looks
like client functionality is working.
Feb 12 08:47:05 onion ntpd[51629]: adjusting clock frequency by -7.934969 to
-23.542969ppm
VMM:
(Originally I forgot 'group internal' in vm.conf, so I put tap1 into group
'internal' manually via ifconfig.)
vm "onion" {
disable
owner jirib
memory 512M
boot $kernel
local interface tap
disk $onion_osdisk
disk $onion_datadisk
}
Networking on host:
~~~
# route -nv show -inet | grep ^default
default176.74.xxx.xxx UGS538658 - 8 em0
"internet4"
# sysctl net.inet.ip.forwarding
net.inet.ip.forwarding=1
em0: flags=8843 mtu 1500
lladdr 90:e2:ba:xx:xx:xx
index 1 priority 0 llprio 3
groups: public egress
media: Ethernet autoselect (100baseTX full-duplex,rxpause,txpause)
status: active
inet 176.74.xxx netmask 0xffe0 broadcast 176.74.xxx
tap1: flags=8843 mtu 1500
lladdr fe:e1:ba:d2:f7:28
description: vm2-if0-onion
index 17 priority 0 llprio 3
groups: tap internal
status: active
inet 100.64.2.2 netmask 0xfffe
PF on host (uses 'group internal'):
~~~
# pfctl -sr | egrep '(on egress.*nat-to|on internal.*all)'
pass out quick on egress from any to route "internet4" flags S/SA nat-to
(egress) round-robin
pass in quick on internal all flags S/SA
Storage on host:
'disk's are located on softraid RAID1 array:
1# bioctl sd8
Volume Status Size Device
softraid0 2 Online 536871947776 sd8 RAID1
0 Online 536871947776 2:0.0 noencl
1 Online 536871947776 2:1.0 noencl
# dmesg | grep ^sd[23]
sd2 at scsibus1 targ 2 lun 0: SCSI3 0/direct
fixed naa.5000c5009387182f
sd2: 953869MB, 512 bytes/sector, 1953525168 sectors
sd3 at scsibus1 targ 3 lun 0: SCSI3 0/direct
fixed naa.5000c500939203ed
sd3: 953869MB, 512 bytes/sector, 1953525168 sectors
dmesg on host:
~~
with disabled lm driver because of issue with bad fan RPM.
OpenBSD 6.2-current (GENERIC.MP) #0: Sat Feb 10 00:05:49 MST 2018
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8564375552 (8167MB)
avail mem = 8297807872 (7913MB)
enter_shared_special_pages: entered idt page va 0x8001 pa 0x1d5a000
enter_shared_special_pages: entered kutext page va 0x81831000 pa
0x1831000
enter_shared_special_pages: entered kutext page va 0x81832000 pa
0x1832000
enter_shared_special_pages: entered kutext page va 0x81833000 pa
0x1833000
enter_shared_special_pages: entered kudata page va 0x81ac8000 pa
0x1ac8000
cpu_enter_pages: entered tss+gdt page at va 0x81ab4000 pa 0x1ab4000
cpu_enter_pages: entered t.stack page at va 0x81ab5000 pa 0x1ab5000
cpu_ente
Re: tor inside vmm, horribly slow?!
On Sun, Feb 11, 2018 at 06:38:49PM -0500, Jiri B wrote: > Hi, > > has anybody tried to run tor inside vmm guest? > > it's horrible slow, just doing 'tor-resolve $dnsname' takes > sometimes ages. > > # dmesg | head -n 4 > OpenBSD 6.2-current (GENERIC.MP) #0: Sat Feb 10 00:05:49 MST 2018 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 520093696 (496MB) > avail mem = 497381376 (474MB) > > is it related to vmm ssl issue reported in the past? > no > # vmstat ; time tor-resolve www.openbsd.org > procsmemory pagediskstraps cpu > r s avm fre flt re pi po fr sr sd0 sd1 int sys cs us sy id > 1 35 42M302M 176 0 0 0 0 0 17 0 124 544 29 0 88 12 > 129.128.5.194 > 0m46.07s real 0m00.00s user 0m00.00s system > > # vmstat ; time tor-resolve www.openbsd.org > procsmemory pagediskstraps cpu > r s avm fre flt re pi po fr sr sd0 sd1 int sys cs us sy id > 1 35 42M302M 166 0 0 0 0 0 15 0 122 514 28 0 88 12 > 129.128.5.194 > 0m00.13s real 0m00.00s user 0m00.00s system > > Jiri > This report sucks. no dmesg, no information about what the VM config is, what version the guest is, what version the host is, etc.
tor inside vmm, horribly slow?!
Hi, has anybody tried to run tor inside vmm guest? it's horrible slow, just doing 'tor-resolve $dnsname' takes sometimes ages. # dmesg | head -n 4 OpenBSD 6.2-current (GENERIC.MP) #0: Sat Feb 10 00:05:49 MST 2018 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 520093696 (496MB) avail mem = 497381376 (474MB) is it related to vmm ssl issue reported in the past? # vmstat ; time tor-resolve www.openbsd.org procsmemory pagediskstraps cpu r s avm fre flt re pi po fr sr sd0 sd1 int sys cs us sy id 1 35 42M302M 176 0 0 0 0 0 17 0 124 544 29 0 88 12 129.128.5.194 0m46.07s real 0m00.00s user 0m00.00s system # vmstat ; time tor-resolve www.openbsd.org procsmemory pagediskstraps cpu r s avm fre flt re pi po fr sr sd0 sd1 int sys cs us sy id 1 35 42M302M 166 0 0 0 0 0 15 0 122 514 28 0 88 12 129.128.5.194 0m00.13s real 0m00.00s user 0m00.00s system Jiri
