I am seeing intermittent resolver failures in /var/log/hobbit/bb-network.log.
This box also runs MRTG, which chews up a lot of resources with as many points as I monitor. The failures appear to occur one minute and 3-10 seconds into the MRTG polling cycle, during which time the box is CPU bound for about 30 seconds (decrypting several thousand SNMP V3 PDU's)
Is there a way to extend the ares resolver timeout? Or is there some local resolver caching I could set up to help mitigate this problem?
At any other point in the MRTG polling cycle the resolver seems to work fine. The other pieces cause the system to be network bound during the initial poll (about 25 seconds), and disk bound (40 seconds) whilst re-writing the ~6000 RRD files.
-- Daniel J McDonald, CCIE # 2495, CISSP # 78281, CNX Austin Energy http://www.austinenergy.com
On Wed, Nov 29, 2006 at 06:40:58AM -0600, Daniel J McDonald wrote:
I am seeing intermittent resolver failures in /var/log/hobbit/bb-network.log.
This box also runs MRTG, which chews up a lot of resources with as many points as I monitor. The failures appear to occur one minute and 3-10 seconds into the MRTG polling cycle, during which time the box is CPU bound for about 30 seconds (decrypting several thousand SNMP V3 PDU's)
Is there a way to extend the ares resolver timeout?
"--dns-timeout=N" (default: 30 seconds) for the bbtest-net program.
Or is there some local resolver caching I could set up to help mitigate this problem?
A local caching DNS server on the Hobbit box doing network tests is always a good idea.
At any other point in the MRTG polling cycle the resolver seems to work fine. The other pieces cause the system to be network bound during the initial poll (about 25 seconds), and disk bound (40 seconds) whilst re-writing the ~6000 RRD files.
So another solution might be to make sure that the MRTG update and the Hobbit network tests do not run at the same time. You can do that if you run the mrtg update from hobbitlaunch instead of through cron; the GROUP keyword for each section in hobbitlaunch.cfg is used to make sure there is only one task belonging to each GROUP running at the same time.
Regards, Henrik
port 1984 bb message protocol, log format are all originated and designed by Quest' BB program. Will hobbit client/server in legal problem later on if Quest decide to enforce per-seat license policy ?
Thanks for your comments
T.J. Yang
Stay up-to-date with your friends through the Windows Live Spaces friends list. http://clk.atdmt.com/MSN/go/msnnkwsp0070000001msn/direct/01/?href=http://spa...
On Wednesday 29 November 2006 14:50, T.J. Yang wrote:
port 1984 bb message protocol, log format are all originated and designed by Quest' BB program. Will hobbit client/server in legal problem later on if Quest decide to enforce per-seat license policy ? No. And even with a yes, all this is easy changed.
Stef
If it copied the code yes but the port wouldn't matter and formatting of the logs wouldn't either, since they are both fairly abstract principles
- you can't sue people for connecting to the same port your program uses or the was they chose to make something look, only if they used your code to do it without authorisation.
Jason.
-----Original Message----- From: Stef Coene [mailto:stef.coene at docum.org] Sent: 29 November 2006 14:13 To: hobbit at hswn.dk Subject: Re: [hobbit] Will hobbit infringe patent/copyright of Quest's bb ?
On Wednesday 29 November 2006 14:50, T.J. Yang wrote:
port 1984 bb message protocol, log format are all originated and designed by Quest' BB program. Will hobbit client/server in legal problem later on if Quest decide to enforce per-seat license policy ? No. And even with a yes, all this is easy changed.
Stef
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
Didn't they submit an RFC for the protocol? That would make it available for anyone to use. A pure Hobbit implementation would not be subject to any Quest decisions. But if you are mixing BB and Hobbit components, then you will have to honor any BB license restrictions.
Of course, I am not a lawyer, and so this viewpoint is based on what sounds reasonable to me, not necessarily on what might get decided in a court. And we all know how courts can sometimes interpret things in a way that is not obvious to most folks.
GLH
-----Original Message----- From: T.J. Yang [mailto:tj_yang at hotmail.com] Sent: Wednesday, November 29, 2006 7:50 AM To: hobbit at hswn.dk Subject: [hobbit] Will hobbit infringe patent/copyright of Quest's bb ?
port 1984 bb message protocol, log format are all originated and designed by Quest' BB program. Will hobbit client/server in legal problem later on if Quest decide to enforce per-seat license policy ?
Thanks for your comments
T.J. Yang
Stay up-to-date with your friends through the Windows Live Spaces friends list. http://clk.atdmt.com/MSN/go/msnnkwsp0070000001msn/direct/01/?href=http:/ /spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mk
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
On Wed, Nov 29, 2006 at 07:50:16AM -0600, T.J. Yang wrote:
port 1984 bb message protocol, log format are all originated and designed by Quest' BB program. Will hobbit client/server in legal problem later on if Quest decide to enforce per-seat license policy ?
I don't think there will be a problem. I am not a lawyer, but here's how I see it:
If Quest were to claim any ownership of the BB procotol or file formats, it would have to be based on either a) trade secret, b) patent, or c) copyright.
a) fails because the BB folks published the protocol for anyone to use; it is documented in the BB on-line help, which is freely accessible for download.
b) fails since AFAIK the communications protocol has not been patented.
c) fails both because Hobbit doesn't use any code from BB, and because copyright does not restrict interoperability and reverse-engineering work. E.g. that is how the Samba team have been able to implement a MS Windows fileserver on Linux without getting into legal problems with Microsoft.
Besides, Hobbit actually uses a very extended version of the BB protocol. I currently regard the BB protocol as a "legacy" compatibility thing only; all of the communication between Hobbit modules already use a different protocol (eg the client->server communication), or will do so within a very short time (the only thing left using standard BB protocol is how the network test results are sent to the Hobbit server, and that will change over the next year).
On a broader scale: I've had this question asked privately a couple of times since Hobbit was first released. I know that Quest is aware of the Hobbit project; I also know that until now they haven't in any way contacted me regarding any kind of "intellectual property" issue. Hobbit has been around for 2 years, so if they had any problems with this I think I would have heard from them by now.
Regards, Henrik
I really appreciate Henrik and others' reply regarding to my post. the analysis of this potential legal issue is good. I will forward the posts to my management for their own interpretation.
Regards
tj
From: henrik at hswn.dk (Henrik Stoerner) Reply-To: hobbit at hswn.dk To: hobbit at hswn.dk Subject: Re: [hobbit] Will hobbit infringe patent/copyright of Quest's bb ? Date: Wed, 29 Nov 2006 18:45:51 +0100
On Wed, Nov 29, 2006 at 07:50:16AM -0600, T.J. Yang wrote:
port 1984 bb message protocol, log format are all originated and
designed
by Quest' BB program. Will hobbit client/server in legal problem later on if Quest decide to enforce per-seat license policy ?
I don't think there will be a problem. I am not a lawyer, but here's how I see it:
If Quest were to claim any ownership of the BB procotol or file formats, it would have to be based on either a) trade secret, b) patent, or c) copyright.
a) fails because the BB folks published the protocol for anyone to use; it is documented in the BB on-line help, which is freely accessible for download.
b) fails since AFAIK the communications protocol has not been patented.
c) fails both because Hobbit doesn't use any code from BB, and because copyright does not restrict interoperability and reverse-engineering work. E.g. that is how the Samba team have been able to implement a MS Windows fileserver on Linux without getting into legal problems with Microsoft.
Besides, Hobbit actually uses a very extended version of the BB protocol. I currently regard the BB protocol as a "legacy" compatibility thing only; all of the communication between Hobbit modules already use a different protocol (eg the client->server communication), or will do so within a very short time (the only thing left using standard BB protocol is how the network test results are sent to the Hobbit server, and that will change over the next year).
On a broader scale: I've had this question asked privately a couple of times since Hobbit was first released. I know that Quest is aware of the Hobbit project; I also know that until now they haven't in any way contacted me regarding any kind of "intellectual property" issue. Hobbit has been around for 2 years, so if they had any problems with this I think I would have heard from them by now.
Regards, Henrik
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
Get the latest Windows Live Messenger 8.1 Beta version.�Join now. http://ideas.live.com
This is another question I will be asked.
Is hobbit development a one-person project or there are many people contributing on the development of this project ?
Browsing from the source code I see names beside Henrik. I am having problem to prepare the answer for this question.
So far, I am thinking to a grep on string with email patten to get a feel how many people contributed.
T.J. Yang
View Athlete�s Collections with Live Search http://sportmaps.live.com/index.html?source=hmemailtaglinenov06&FORM=MGAC01
I did a find+grep for email address and adding names from Credit file in source.
I found there are 51 persons contribute to this project.
http://en.wikibooks.org/wiki/System_Monitoring_with_Hobbit/Developer_Guide#D...
T.J. Yang
From: "T.J. Yang" <tj_yang at hotmail.com> Reply-To: hobbit at hswn.dk To: hobbit at hswn.dk Subject: [hobbit] How big is the hobbit development community ? Date: Wed, 29 Nov 2006 14:43:08 -0600
This is another question I will be asked.
Is hobbit development a one-person project or there are many people contributing on the development of this project ?
Browsing from the source code I see names beside Henrik. I am having problem to prepare the answer for this question.
So far, I am thinking to a grep on string with email patten to get a feel how many people contributed.
T.J. Yang
View Athlete�s Collections with Live Search http://sportmaps.live.com/index.html?source=hmemailtaglinenov06&FORM=MGAC01
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
Get free, personalized commercial-free online radio with MSN Radio powered by Pandora http://radio.msn.com/?icid=T002MSN03A07001
On Wed, 2006-11-29 at 13:51 +0100, Henrik Stoerner wrote:
On Wed, Nov 29, 2006 at 06:40:58AM -0600, Daniel J McDonald wrote:
I am seeing intermittent resolver failures in /var/log/hobbit/bb-network.log.
[...]
Or is there some local resolver caching I could set up to help mitigate this problem?
A local caching DNS server on the Hobbit box doing network tests is always a good idea.
A new instance of bind seems to have resolved the issue.
At any other point in the MRTG polling cycle the resolver seems to work fine. The other pieces cause the system to be network bound during the initial poll (about 25 seconds), and disk bound (40 seconds) whilst re-writing the ~6000 RRD files.
So another solution might be to make sure that the MRTG update and the Hobbit network tests do not run at the same time. You can do that if you run the mrtg update from hobbitlaunch instead of through cron; the GROUP keyword for each section in hobbitlaunch.cfg is used to make sure there is only one task belonging to each GROUP running at the same time.
This would not likely work. The total time that MRTG runs is about 3 minutes 40 seconds, with a fair chunk of that single-threaded (and thus not CPU bound on my multi-processor box). To limit bb-net tests to just that small timeslice eliminates some the the cool benefits of hobbit, like 1-minute retries...
-- Daniel J McDonald, CCIE # 2495, CISSP # 78281, CNX Austin Energy http://www.austinenergy.com
participants (6)
-
dan.mcdonald＠austinenergy.com
-
greg.hubbard＠eds.com
-
henrik＠hswn.dk
-
JasonAS_Jones＠mentor.com
-
stef.coene＠docum.org
-
tj_yang＠hotmail.com