search for: tickl

Address some credit2 issues. This patch series, along with the recent changes to the cpupools interface, should address some of the strange credit2 instability. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

Hello, This small series deals with some weirdness in the mechanism with which the credit scheduler choses what PCPU to tickle upon a VCPU wake-up. Details are available in the changelog of the first patch. The new approach has been extensively benchmarked and proved itself either beneficial or harmless. That means it does not introduce any significant amount of overhead and/or performances regressions while, for some w...

Hi, I just took this test on Tickle.com. What''s Your Fame and Fortune? http://web.tickle.com/invite?test=1177&type=t Take it and see how you score. You can see my score at the end. Surekha -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/att...

...he network cable of serving node A ->NFS Client took 20 minutes to recover to conitinue writing. It is too slow for clients to accept the recovery time�� From CTDB log, during failover and failback, fail node failed to kill the connection with client while recovery node failed to send ��tickle ack��to client to re-established connection. So during 1~3s ��takeover is failed�� Why is it failed to fast recovery and took 20 minutes to recovery successfully. Is there anyone knows the reason? We are looking forward to your reply. Thanks. -----------------------------------------...

...> The next possible points of failure would be if packets sent by ctdbd > were not delivered/processed, because CTDB basically uses network > tricks to encourage clients to disconnect and reconnect quickly. There > are 2 types of packets sent by the takeover node: > > * TCP "tickle" ACKs > > These are sent to clients to wake them up and cause their connection > to terminated, so they reconnect: > ... > This is repeated 3 times. For the point in time noted above I see 308 "sending tcp tickle ack for 2049-><IP:Port>" messages. A...

OpenSSH 5.1p1 I can't grasp why, when connecting with 'ssh -Y' to this test host, I am not tickling the verbose() call below that I have added. I am logging as auth + verbose in sshd_config The X11 forward for the session works fine as tested with xterm. At any rate, I am looking for some guidance on where to log X11 forwards that are established, ideally with a username and remote display...

...lock_ip part isn't working (and you would expect to > > see errors from iptables) because they are new connections. > > I have not seen any errors from iptables. > So, I think it is (2). :-) The problem seems to be that ctdb_killtcp is not capturing a response to its TCP tickle ACK. ctdb_killtcp needs to do things specially because it is trying to terminate TCP connections on the releasing side when the IP address is still hosted and the connections actually exist. This is different to the takeover side, where only the TCP tickle ACK is sent, and the client and server...

On 06/06/2020 3:44 p.m., Duncan Murdoch wrote: > On 06/06/2020 3:06 p.m., Dirk Eddelbuettel wrote: ... [deletions] >> In short, 4.0.0 no longer exports via 'exportPattern("^[[:alpha:]]+")' >> rendering the new package created non-functional. >> >> Was this intentional, or is this a bug we can look into fixing for R 4.0.2 ? > > It's in the

Hello, I am beginning to front my Asterisk cluster with OpenSIPS/Kamailio and so far my biggest issue is the complete lack of quick-start-like documentation for either. Is there any place I can get a very simple HA configuration (telling me where the config files are, for starters, is a good thing) for OpenSIPS or Kamailio with the following features: (a) Support an arbitrarily large number of

...nt must be a multiple of 3 , and the ovector argument must point to a location that can hold at least ovecsize integers. All the pcre_exec calls made by do_grep, save one, honors this. That one call seems to overwrite areas of the stack it shouldn't. Here's the smallest example I found that tickles the bug: > grep("[^[:blank][:cntrl]]","\\n",perl=TRUE) Error in grep("[^[:blank][:cntrl]]", "\\n", perl = TRUE) : negative length vectors are not allowed As described above, this error occurs on ubuntu 10.04 when R is compiled without optimizations (...

...ns of a file in the same directory as the main file. We are therefore evaluating how stable and efficient different combinations of file systems would be in this scenario. We've run our versionfs on ext2 and ext3, and with and without the HTree patches. We started with 2.4.20, and managed to tickle the "buffer credits" bug reported here: http://www.spinics.net/lists/ext3/msg02297.html So we went to 2.4.21 and 2.4.22, as they include the patch reported in the above message. But we're still getting the bug. We can reproduce it using postmark inside versionfs, mounted on top...

...hout substantial re-writing. The next possible points of failure would be if packets sent by ctdbd were not delivered/processed, because CTDB basically uses network tricks to encourage clients to disconnect and reconnect quickly. There are 2 types of packets sent by the takeover node: * TCP "tickle" ACKs These are sent to clients to wake them up and cause their connection to terminated, so they reconnect: 1. A TCP ACK is sent with a sequence number of 0 (and an identifying window size of 1234, which is easy to see in tcpdump or similar). 2. The client responds to this no...

...approach should be preferred. It also has room for more performance tweaking and makes caching more obvious. - Increasing the depth of the known bits search at which dominating conditions are applied increases compile time without material improvement in result quality. - Enabling this seems to tickle a lot of unrelated bugs. Taking the time to triage those might be good purely from a robustness standpoint since in *theory* this is just returning a result the known bits could have figured out otherwise. - At least for me, the ability to reason about non-nullness is more important than the...

...mp it all the way to +19 and still it consumes 100% of the CPU. The result for asterisk is that I hear bits of robot noise during conversations, which is annoying as hell but not neccessarily show stopping. But for another 19 days?? Argg! I assume that because it is 'modprobe' it has tickled some kernel bug that is merrily spinning away and won't respond to interrupts. I even tried to stop it with gdb and strace, both of which also hung and had to be killed with -9. It seems to be related to me screwing with the iptables a few weeks ago. Any ideas other than rebooting? Che...

...odest here to not mention the *fabulous* tool he has written (with the [financial] support of the R Consortium): R Hub. These days I just do 'rhub::check_for_cran()' and four tests launch covering the three required OSs as well as the required r-devel and r-release versions. Results tickle in within minutes by mail; the windows one (which is slowest) is also display. You need a one-time token handshake. I strongly recommend the service. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org

The Linux implementation of TCP sockets has a bug which causes shutdown(sock, SHUT_RD) to fail spuriously (ENOTCONN) if the write side of the socket has already been shut down. If you are using SSH port forwarding to tunnel HTTP through a firewall, nchan.c will tickle this bug once for every HTTP exchange. You will therefore get lots of useless, annoying error messages: channel 2: chan_shutdown_read: shutdown() failed for fd7 [i1 o128]: Transport endpoint is not connected Here's a complete debugging trace of one such forwarded channel. This is SSH1 prot...

There's a problem with LLVM version 2.5 compiled under G++ 4.1.2 which involves computing the cost of inlining a function. It works fine in a debug build. However, the Release build seems to tickle a g++ bug. Here is the code, from InlineCost.h: class InlineCost { enum Kind { Value, Always, Never }; int Cost : 30; unsigned Type : 2; InlineCost(int C, int T) : Cost(C), Type(T) { assert(Cost == C && "Cost exceeds InlineCost precis...

On 6 August 2011 23:05, Jason Kim <jasonwkim at google.com> wrote: > Hi everyone, > -r136747 of llvm-gcc (and possibly others) is apparently tickling a binutils > issue on linux x86-64 > Has anyone seen anything like this? Yes, it looks like this: http://sourceware.org/bugzilla/show_bug.cgi?id=12887 I think switching from ld to gold might be an effective work-around. Jay.

...port with Redhat ... > > By bug report you mean BZ or a support request as paying RHEL customer? A BZ ... > Unfortunately I'm not too happy anymore with how BZs are handled these > days. Am I alone with this feeling? I've had mixed results with BZs - it appears if a bug 'tickles the fancy' of someone a Redhat that sees the ticket, then you can get good results - otherwise, they just sit there until the release goes out of support and they get dropped :-) James Pearson

...clients to accept the recovery time。 Definitely! What was different between "1st" and "2nd"? Were they testing different scenarios? > From CTDB log, during failover and failback, fail node failed to kill > the connection with client while recovery node failed to send ‘tickle > ack’to client to re-established connection. The first really isn't a problem. I'm not sure why CTDB attempts to do a 2 way kill from the releasing node. We're going to stop doing that in the future. The 2nd is a mystery. Are you sure the network connection on node B was up?...