[CLOSED] Slow Terminal Action about urbit HOT 30 CLOSED

Comment by johncburnham
Thursday Sep 26, 2013 at 13:26 GMT

In reverse order:

:ls % isn't giving you output because :ls is a file that you need to pull from ~zod. If you can't connect to ~zod for the initial update, very few commands work.

You ship's probably out of sync. Did you delete and recreate your destroyers as outlined in Curtis' post to the mailing list? https://groups.google.com/d/msg/urbit-dev/FQqNyi15lu0/GB7Fgyk_wVQJ

~zod is up right now, so once you get reconnected, let's see if the terminal slowness is still there.

keep in mind, everything's inherently slow right now. it's not atrocious for an alpha version, but things will be much much better once we hit continuity (and thus beta) next week.

from urbit.

Comment by yebyen
Thursday Sep 26, 2013 at 13:53 GMT

I hadn't got the daily digest yet. I read the initial warning that this was coming before Oct 4, but I didn't think that would mean "tomorrow" :)

I should have checked the mailing list before I tweeted. Thanks!

from urbit.

Comment by yebyen
Thursday Sep 26, 2013 at 14:57 GMT

I am back on the network and I appear to have pulled down all the "binaries" from zod. It is still just as slow. I don't know what these ships are doing when I load them up; if I have a submarine and two destroyers, will they work together on their own (?) -- is it necessary to run them all at the same time on different hosts? I'm familiar with zookeeper enough to know that you need at least 3 zookeepers to have a working cluster (not two, and certainly not one, but always an odd number)

Does it work like that?

EDIT: OK so maybe not "just as slow" but there is a sizeable delay

from urbit.

Comment by yebyen
Thursday Sep 26, 2013 at 15:43 GMT

It's probably a tolerable speed now, with just one submarine.

Thanks for making a neat thing!

from urbit.

Comment by johncburnham
Thursday Sep 26, 2013 at 15:46 GMT

We've got a big update coming, even before continuity, that should help the network performance. Just one of the innumerable things we've got to get done.

from urbit.

Comment by cgyarvin
Thursday Sep 26, 2013 at 16:37 GMT

~zod/~doznec was down. Alas, it happens. The error on 'ls' is that the
file doesn't exist, since your destroyer didn't sync.

~ /cx/~divsem-misdef/try/~2013.9.26..12.18.19..6428/bin/ls/hoon

The "state D" thing is very interesting. The thing is, we shouldn't be
doing blocking I/O. We're using libuv, dammit! Others have reported this
bug... and I've never seen it on OS/X or Linux. I wonder if the
virtualization is an issue.

Unfortunately, yebyen, this makes you a valuable resource. If you can
chase down where the process is blocked, that'd be very useful...

On Thu, Sep 26, 2013 at 5:52 AM, yebyen [email protected] wrote:

From the time I type ":infinite" to the time it shows up on my screen is
at least a full 10 seconds. There is nothing else eating up cycles during
this time. The vere process shows in top as state D (blocking I/O) until
the typing is finally echoed to the screen.

Today it tells me ~zod |Tianming| not responding still trying, it hasn't
said that before, but I've always had the same slow typing results. Same
result with submarines or destroyers. It does not have to be ":infinite"
but typing anything, with or without newline. Today I also don't get output
from :ls %:

~divsem-misdef/try=> :ls %
~ /cx/~divsem-misdef/try/~2013.9.26..12.18.19..6428/bin/ls/hoon

My environment is Ubuntu Linux under Docker (CoreOS/Vagrant)

The host system is Windows 7
It's an SSD-bearing laptop with four cores, so there are no local barriers
that I know of that should cause blocking for that long. Is it reaching out
to the internet to act on these commands? Should it be blocking I/O?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/20
.

from urbit.

Comment by vrotaru
Thursday Sep 26, 2013 at 16:59 GMT

I have the same issue, using Fedora 19 (64bit if that matters). On the other side playing with Arvo/Urbit in VMWare client (Windows 7) with Debian freshly installed I did not have that issue.

I must be system specific. Currently I'm running the latest from the github

from urbit.

Comment by yebyen
Thursday Sep 26, 2013 at 17:30 GMT

Oh, ok! It doesn't have to be unfortunate if I am a valuable resource :)

I have done this before using... strace. Unfortunately the output of strace is of absolutely ridiculous proportions even in trivial programs, and this is not a trivial program...

I see a lot of fdatasync, epoll_wait, clock_gettime when things settle down.
There appear to be segmentation violations left and right (SIGSEGV).

Performance has got a lot better trying it right now, but I don't have to touch a lot of keys to see it enter D state.

I can try and just capture all of the output of strace, does that help? Is there something you'd rather get?

from urbit.

Comment by yebyen
Thursday Sep 26, 2013 at 17:35 GMT

I'm going to bet that it's something docker does with cgroups and namespaces, not something that VirtualBox or Vagrant is doing, based on nothing but intuition. Let me know if there's an IRC channel I should join, or another way you'd prefer to continue the debugging dialog.

from urbit.

Comment by cgyarvin
Thursday Sep 26, 2013 at 18:05 GMT

Ooh! That makes me so mad! Cruiser to anyone who can find this. It's
undoubtedly some bad interaction in the bowels of libuv...

On Thu, Sep 26, 2013 at 9:59 AM, Vasile Rotaru [email protected]:

I have the same issue, using Fedora 19 (64bit if that matters). On the
other side playing with Arvo/Urbit in VMWare client (Windows 7) with Debian
freshly installed I did not have that issue.

I must be system specific. Currently I'm running the latest from the github

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/20#issuecomment-25184542
.

from urbit.

Comment by cgyarvin
Thursday Sep 26, 2013 at 18:09 GMT

You know, I really don't want to create an IRC channel, because Urbit is
designed to be its own IRC channel. I haven't started using this because
the network remains a bit flaky, but we will...

The sigsegvs are normal - they're part of how we do checkpointing. Above
(I would encourage anyone doing active development, by the way, to switch
their urbit-dev defaults away from digest mode) someone is reporting the
slowbug on 64-bit Fedora with no virtualization/docker.

The question is simply what it's doing when it's in D mode. Somewhere,
somehow, an I/O operation is blocking. All I need is to know is where...
and yes, any kind of trace is (potentially) useful.

On Thu, Sep 26, 2013 at 10:35 AM, yebyen [email protected] wrote:

I'm going to bet that it's something docker does with cgroups and
namespaces, not something that VirtualBox or Vagrant is doing, based on
nothing but intuition. Let me know if there's an IRC channel I should join,
or another way you'd prefer to continue the debugging dialog.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/20#issuecomment-25187327
.

from urbit.

Comment by vrotaru
Thursday Sep 26, 2013 at 19:01 GMT

So this is what I get from

    strace -c -p $vere_pid

when I'm doing a :ls % and here is what I get. Subjectively it is about a second from the time I press the key and when something appears on screen.

% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 68.88    0.062000         112       555           fsync
 21.95    0.019758           7      2741           read
  4.51    0.004055           6       717           write
  1.59    0.001434           3       554           lseek
  1.16    0.001047           2       651           mprotect
  0.77    0.000695          17        40           fdatasync
  0.26    0.000234           2       152           open
  0.20    0.000177           9        20           ftruncate
  0.17    0.000154           4        38           sigaltstack
  0.13    0.000114           1       228           rt_sigprocmask
  0.12    0.000105          11        10           sendmsg
  0.09    0.000083           1       152           close
  0.09    0.000078           0       631           rt_sigreturn
  0.08    0.000072           2        32        12 epoll_ctl
  0.00    0.000000           0         8           brk
  0.00    0.000000           0       247           rt_sigaction
  0.00    0.000000           0        38           setitimer
  0.00    0.000000           0        12         4 recvmsg
  0.00    0.000000           0        23           epoll_wait
------ ----------- ----------- --------- --------- ----------------
100.00    0.090006                  6849        16 total

from urbit.

Comment by cgyarvin
Thursday Sep 26, 2013 at 19:25 GMT

Alas, this doesn't tell me anything - as you see, the number of seconds
consumed in CPU processing is much smaller than your delay. Whatever is
taking the time, it is not the CPU in userspace mode.

I wonder about fsync() and fdatasync() - it's a little surprising how often
fdatasync() is called. If you comment out the calls to both these
functions in v/*.c, does the delay go away?

On Thu, Sep 26, 2013 at 12:01 PM, Vasile Rotaru [email protected]:

So this is what I get from

strace -c -p $vere_pid

when I'm doing a :ls % and here is what I get. Subjectively it is about a
second from the time I press the key and when something appears on screen.

% time seconds usecs/call calls errors syscall

---

68.88 0.062000 112 555 fsync
21.95 0.019758 7 2741 read
4.51 0.004055 6 717 write
1.59 0.001434 3 554 lseek
1.16 0.001047 2 651 mprotect
0.77 0.000695 17 40 fdatasync
0.26 0.000234 2 152 open
0.20 0.000177 9 20 ftruncate
0.17 0.000154 4 38 sigaltstack
0.13 0.000114 1 228 rt_sigprocmask
0.12 0.000105 11 10 sendmsg
0.09 0.000083 1 152 close
0.09 0.000078 0 631 rt_sigreturn
0.08 0.000072 2 32 12 epoll_ctl
0.00 0.000000 0 8 brk
0.00 0.000000 0 247 rt_sigaction
0.00 0.000000 0 38 setitimer
0.00 0.000000 0 12 4 recvmsg
0.00 0.000000 0 23 epoll_wait

---

100.00 0.090006 6849 16 total

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/20#issuecomment-25194045
.

from urbit.

Comment by yebyen
Thursday Sep 26, 2013 at 19:38 GMT

Nope, it's still holding the terminal after a certain amount of keyboard input. It seems like the amount has gotten larger since I started testing this earlier. I'm not sure that commenting those lines was enough, I've got strace -p running in a different terminal now, and it is calling fdatasync and fsync repeatedly while the D state is hanging.

from urbit.

Comment by radiofreejohn
Thursday Sep 26, 2013 at 19:38 GMT

Ditto for me with the delay, I'm also not able to recreate my destroyers but I predict I've done something else wrong along the way.

% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 84.48    0.083359          10      8114           read
  7.11    0.007012          23       300           open
  3.14    0.003102           5       689           mprotect
  2.26    0.002228           6       394           fsync
  2.25    0.002219           7       300           close
  0.36    0.000354           1       685           rt_sigreturn
  0.31    0.000305           1       392           lseek
  0.09    0.000093           0       422           write
  0.00    0.000000           0         8           gettimeofday
  0.00    0.000000           0         4           ftruncate
  0.00    0.000000           0         6           setitimer
  0.00    0.000000           0         8           fdatasync
  0.00    0.000000           0        39           rt_sigaction
  0.00    0.000000           0        36           rt_sigprocmask
  0.00    0.000000           0         6           sigaltstack
  0.00    0.000000           0         6         2 epoll_ctl
  0.00    0.000000           0         5           epoll_wait
  0.00    0.000000           0        11           clock_gettime
  0.00    0.000000           0         6         6 openat
  0.00    0.000000           0        11           sendmsg
------ ----------- ----------- --------- --------- ----------------
100.00    0.098672                 11442         8 total

Also, this is what appears (a portion) just before the output of %ls

rt_sigreturn(0x847f4e)                  = 1112387764
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
mprotect(0x42513000, 16384, PROT_READ|PROT_WRITE) = 0
rt_sigreturn(0x8f3b6a)                  = 1112387764
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
mprotect(0x42967000, 16384, PROT_READ|PROT_WRITE) = 0
rt_sigreturn(0x8b9f1a)                  = 1112387764
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
mprotect(0x426af000, 16384, PROT_READ|PROT_WRITE) = 0
rt_sigreturn(0x923eee)                  = 1112387764
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
mprotect(0x42657000, 16384, PROT_READ|PROT_WRITE) = 0
rt_sigreturn(0x875fda)                  = 1112387764
write(0, "\r\n", 2)                     = 2
write(0, "\r", 1)                       = 1
write(0, "\33[J", 3)                    = 3
write(0, "bin lib web", 11)             = 11
write(0, "\r\n", 2)                     = 2
write(0, "\r", 1)                       = 1
write(0, "\33[J", 3)                    = 3
write(0, "~bitnyl-folfet-maptyp-palwet--ma"..., 64) = 64

And many repetitions of this:

mprotect(0x60983000, 16384, PROT_READ|PROT_WRITE) = 0
rt_sigreturn(0x404db004)                = 135438337
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
open("/proc/self/maps", O_RDONLY)       = 21
read(21, "08048000-080cc000 r-xp 00000000 "..., 1024) = 1024
...
read(21, "   /lib/i386-linux-gnu/libtinfo."..., 1024) = 951
close(21)                               = 0
mprotect(0x60987000, 16384, PROT_READ|PROT_WRITE) = 0
rt_sigreturn(0x404db004)                = 135442435
rt_sigaction(SIGTERM, {SIG_IGN, [TERM], SA_RESTART}, {0x804ebe0, [TERM], SA_RESTART}, 8) = 0
rt_sigaction(SIGVTALRM, {SIG_IGN, [VTALRM], SA_RESTART}, {0x804ebb0, [VTALRM], SA_RESTART}, 8) = 0
rt_sigaction(SIGSEGV, {0xb76b0ad0, [HUP INT QUIT USR1 USR2 PIPE ALRM TERM CHLD URG XCPU XFSZ VTALRM PROF WINCH IO PWR], SA_SIGINFO}, NULL, 8) = 0
sigaltstack({ss_sp=0x80000000, ss_flags=SS_DISABLE, ss_size=0}, NULL) = 0
setitimer(ITIMER_VIRTUAL, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0
rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], [], 8) = 0

from urbit.

Comment by cgyarvin
Thursday Sep 26, 2013 at 19:41 GMT

John, did you try recreating your destroyers from a new submarine?

The mprotect() and sigsegvs are totally normal - that's part of the
checkpointing process.

I think it's clear that there's some blocking I/O going on somewhere. I
wonder if anyone can create this problem in a boxed-up virtual machine
where I can replicate it? It doesn't happen on any bare OS I have access
to.

On Thu, Sep 26, 2013 at 12:38 PM, John [email protected] wrote:

Ditto for me with the delay, I'm also not able to recreate my destroyers
but I predict I've done something else wrong along the way.

% time seconds usecs/call calls errors syscall

---

84.48 0.083359 10 8114 read
7.11 0.007012 23 300 open
3.14 0.003102 5 689 mprotect
2.26 0.002228 6 394 fsync
2.25 0.002219 7 300 close
0.36 0.000354 1 685 rt_sigreturn
0.31 0.000305 1 392 lseek
0.09 0.000093 0 422 write
0.00 0.000000 0 8 gettimeofday
0.00 0.000000 0 4 ftruncate
0.00 0.000000 0 6 setitimer
0.00 0.000000 0 8 fdatasync
0.00 0.000000 0 39 rt_sigaction
0.00 0.000000 0 36 rt_sigprocmask
0.00 0.000000 0 6 sigaltstack
0.00 0.000000 0 6 2 epoll_ctl
0.00 0.000000 0 5 epoll_wait
0.00 0.000000 0 11 clock_gettime
0.00 0.000000 0 6 6 openat
0.00 0.000000 0 11 sendmsg

---

100.00 0.098672 11442 8 total

Also, this is what appears (a portion) just before the output of %ls

rt_sigreturn(0x847f4e) = 1112387764
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
mprotect(0x42513000, 16384, PROT_READ|PROT_WRITE) = 0
rt_sigreturn(0x8f3b6a) = 1112387764
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
mprotect(0x42967000, 16384, PROT_READ|PROT_WRITE) = 0
rt_sigreturn(0x8b9f1a) = 1112387764
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
mprotect(0x426af000, 16384, PROT_READ|PROT_WRITE) = 0
rt_sigreturn(0x923eee) = 1112387764
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
mprotect(0x42657000, 16384, PROT_READ|PROT_WRITE) = 0
rt_sigreturn(0x875fda) = 1112387764
write(0, "\r\n", 2) = 2
write(0, "\r", 1) = 1
write(0, "\33[J", 3) = 3
write(0, "bin lib web", 11) = 11
write(0, "\r\n", 2) = 2
write(0, "\r", 1) = 1
write(0, "\33[J", 3) = 3
write(0, "~bitnyl-folfet-maptyp-palwet--ma"..., 64) = 64

And many repetitions of this:

mprotect(0x60983000, 16384, PROT_READ|PROT_WRITE) = 0
rt_sigreturn(0x404db004) = 135438337
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
open("/proc/self/maps", O_RDONLY) = 21
read(21, "08048000-080cc000 r-xp 00000000 "..., 1024) = 1024
...
read(21, " /lib/i386-linux-gnu/libtinfo."..., 1024) = 951
close(21) = 0
mprotect(0x60987000, 16384, PROT_READ|PROT_WRITE) = 0
rt_sigreturn(0x404db004) = 135442435
rt_sigaction(SIGTERM, {SIG_IGN, [TERM], SA_RESTART}, {0x804ebe0, [TERM], SA_RESTART}, 8) = 0
rt_sigaction(SIGVTALRM, {SIG_IGN, [VTALRM], SA_RESTART}, {0x804ebb0, [VTALRM], SA_RESTART}, 8) = 0
rt_sigaction(SIGSEGV, {0xb76b0ad0, [HUP INT QUIT USR1 USR2 PIPE ALRM TERM CHLD URG XCPU XFSZ VTALRM PROF WINCH IO PWR], SA_SIGINFO}, NULL, 8) = 0
sigaltstack({ss_sp=0x80000000, ss_flags=SS_DISABLE, ss_size=0}, NULL) = 0
setitimer(ITIMER_VIRTUAL, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0
rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], [], 8) = 0

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/20#issuecomment-25196926
.

from urbit.

Comment by yebyen
Thursday Sep 26, 2013 at 19:43 GMT

Docker is all about boxed-up virtual machines. I could send you mine. Let me check to make sure I haven't left any password hashes anywhere.

from urbit.

Comment by yebyen
Thursday Sep 26, 2013 at 19:50 GMT

If you get Docker, you can pull yebyen/cgyarvin and you'll have my destroyer 'satnum' where the problem is happening for me.

source /.bash_profile
cd home/urbit-master
bin/vere hobnob

If by chance it's an artifact of the kernel (3.10.10) or other system bits (it's CoreOS, which has been having a bit of an update problem in the last few days, so it might not be the very latest CoreOS) you won't see the problem.

It's all pushed. Have a look see. The image is close to 3GB (sorry) because it includes some testnet bitcoin altchain I've been hashing on and an example ChicagoBoss app from the PDF tutorial I've been following along with.

(I can also export to a tar file but docker is built for doing this...)

from urbit.

Comment by cgyarvin
Thursday Sep 26, 2013 at 19:56 GMT

Hm, I get a username/password prompt when I try to:

oxford:~/Documents/src; git pull https://github.com/yebyen/cgyarvin.git
Username:
Password:

I do suspect it might be a kernel thing, though. Well, if so, that'll
narrow it down...

On Thu, Sep 26, 2013 at 12:50 PM, yebyen [email protected] wrote:

If you get Docker, you can pull yebyen/cgyarvin and you'll have my
destroyer 'satnum' where the problem is happening for me.

source /.bash_profile
cd home/urbit-master
bin/vere hobnob

If by chance it's an artifact of the kernel (3.10.10) or other system bits
(it's CoreOS, which has been having a bit of an update problem in the last
few days, so it might not be the very latest CoreOS) you won't see the
problem.

It's all pushed. Have a look see. The image is close to 3GB (sorry)
because it includes some testnet bitcoin altchain I've been hashing on and
an example ChicagoBoss app from the PDF tutorial I've been following along
with.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/20#issuecomment-25198066
.

from urbit.

Comment by yebyen
Thursday Sep 26, 2013 at 19:58 GMT

No, it's not on Git, you want this one: https://index.docker.io/u/yebyen/cgyarvin/

Unfortunately not sure how you can download from the docker index without docker. I'll start exporting to tar.

from urbit.

Comment by cgyarvin
Thursday Sep 26, 2013 at 19:59 GMT

Well, I need Docker to run it! Point me to some stupid person docker doc
to show me what I should do.

On Thu, Sep 26, 2013 at 12:58 PM, yebyen [email protected] wrote:

No, it's not on Git, you want this one:
https://index.docker.io/u/yebyen/cgyarvin/

Unfortunately not sure how you can download from the docker index without
docker. I'll start exporting to tar.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/20#issuecomment-25198660
.

from urbit.

Comment by yebyen
Thursday Sep 26, 2013 at 20:02 GMT

If you're in Ubuntu Linux, you're 2/3 of the way there...

http://www.docker.io/gettingstarted/#h_installation

You want:

docker pull yebyen/cgyarvin
docker run -i -t yebyen/cgyarvin /bin/bash

before doing

source /.bash_profile
cd home/urbit-master
bin/vere hobnob

I don't actually install docker though, so I start here:
http://coreos.com/blog/coreos-vagrant-images/

If you are using CoreOS (and possibly if you're not) you'll have to do the docker run command twice to get a shell, because of some weird bug involving fork and lxc-start.

from urbit.

Comment by cgyarvin
Thursday Sep 26, 2013 at 20:09 GMT

I'm in OS X - so don't expect immediate results :-)

On Thu, Sep 26, 2013 at 1:02 PM, yebyen [email protected] wrote:

If you're in Ubuntu Linux, you're 2/3 of the way there...

http://www.docker.io/gettingstarted/#h_installation

You want:

docker pull yebyen/cgyarvin
docker run -i -t yebyen/cgyarvin /bin/bash

before doing

source /.bash_profile
cd home/urbit-master
bin/vere hobnob

I don't actually install docker though, so I start here:
http://coreos.com/blog/coreos-vagrant-images/

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/20#issuecomment-25198966
.

from urbit.

Comment by yebyen
Thursday Sep 26, 2013 at 20:17 GMT

OK :) The coreos/vagrant path is the quickest to an identical setup. I'm using Windows 7, so ^_^

from urbit.

Comment by cgyarvin
Thursday Sep 26, 2013 at 20:40 GMT

Cool. One day maybe I'll rock as much as docker. Anyway I have something
else I need to fix first, but this is my next priority...

On Thu, Sep 26, 2013 at 1:17 PM, yebyen [email protected] wrote:

OK :) The coreos/vagrant path is the quickest to an identical setup. I'm
using Windows 7, so ^_^

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/20#issuecomment-25200112
.

from urbit.

Comment by radiofreejohn
Thursday Sep 26, 2013 at 21:06 GMT

@cgyarvin still no love:

generating 2048-bit RSA key...
; ~doznec not responding still trying
[waiting...]

from urbit.

Comment by cgyarvin
Thursday Sep 26, 2013 at 21:14 GMT

See latest urbit-dev reply.

On Thu, Sep 26, 2013 at 2:06 PM, John [email protected] wrote:

@cgyarvin https://github.com/cgyarvin still no love:

generating 2048-bit RSA key...
; ~doznec not responding still trying
[waiting...]

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/20#issuecomment-25203924
.

from urbit.

Comment by vrotaru
Friday Sep 27, 2013 at 05:42 GMT

My idea, when posting the strace output was to compare it with the same output on a box without those problems, and bellow is the same output (during :ls %) on Debian under VMPlayer under Windows 7

Well, there is quite a difference . Unfortunately, I tells me very little about what the problem could be.

% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
100.00    0.001074          12        88           fsync
  0.00    0.000000           0      1186           read
  0.00    0.000000           0       159           write
  0.00    0.000000           0       143           open
  0.00    0.000000           0       143           close
  0.00    0.000000           0        86           lseek
  0.00    0.000000           0       191           mprotect
  0.00    0.000000           0        78           rt_sigaction
  0.00    0.000000           0        72           rt_sigprocmask
  0.00    0.000000           0       183           rt_sigreturn
  0.00    0.000000           0        12           setitimer
  0.00    0.000000           0        16           fdatasync
  0.00    0.000000           0         8           ftruncate
  0.00    0.000000           0        12           sigaltstack
  0.00    0.000000           0        14           epoll_wait
  0.00    0.000000           0        24        12 epoll_ctl
------ ----------- ----------- --------- --------- ----------------
100.00    0.001074                  2415        12 total

from urbit.

Comment by johncburnham
Friday Sep 27, 2013 at 10:53 GMT

Curtis, you think this might have something to do with the clock_gettime bug we ran into when I was configuring the AWS build? We fixed that by adding -lrt to the makefile, but if glibc was behaving differently on Ubuntu vs AWS it could also be doing something different here. But clock_gettime's only appearing on radiofreejohn's strace (and fsync seems to be behaving normally for him). So maybe this is actually two different system-dependent bugs...

radiofreejohn, what are you building on?

from urbit.

Comment by cgyarvin
Friday Sep 27, 2013 at 11:30 GMT

There is quite a difference but I also am unsure if it is even related to
the bug.

Yebyen sent me a docker image which I'll pound on personally today...

On Fri, Sep 27, 2013 at 3:53 AM, johncburnham [email protected]:

I see Curtis, you think this might have something to do with the
clock_gettime bug we ran into when I was configuring the AWS build? We
fixed that by adding -lrt to the makefile, but if glibc was behaving
differently on Ubuntu vs AWS it could also be doing something different
here. But clock_gettime's only appearing on radiofreejohn's strace (and
fsync seems to be behaving normally for him). So maybe this is actually two
different system-dependent bugs...

radiofreejohn, what are you building on?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/20#issuecomment-25237149
.

from urbit.