[Bismark-devel] FCC app progress: django

[Bismark-devel] FCC app progress: django

[Nick Feamster]

(sorry for list cross-posting)

Srikanth, Abhishek, Walter,

Small, slow progress on the FCC app---

I have a written a very simple server with django.  I've got the django server hooked up to our bismark mysql database.  It's basically a slick python wrapper for doing Web development with a database back-end.   The setup is ugly right now, but it's a proof of concept, and it works (django is talking to our back-end).  For example:
http://networkdashboard.org:8000/summary/

Django has templates that will allow us to make this slick and pretty, but it's getting a little late for that tonight.

I think we can whip up some quick visualizations of what's in the DB with a nice Web page with some concerted python hacking.  For starters, it would be nice to have a version of the data whereby queries can actually complete in a reasonable time.  :-)  What's the best way to do this?  Split the table by months?

I will check what I have into the bismark source tree so that others can work on this.  (I'm looking at Abhishek :-)

-Nick

Re: [Bismark-devel] [Hndr] FCC app progress: django

[Nick Feamster]

Got the django-backed production server up and running at http://networkdashboard.org/

woot!  we are ready to go.  will check in to bismark svn first thing tomorrow.

-Nick

On Apr 18, 2011, at 1:57 AM, Nick Feamster wrote:

> (sorry for list cross-posting)
> 
> Srikanth, Abhishek, Walter,
> 
> Small, slow progress on the FCC app---
> 
> I have a written a very simple server with django.  I've got the django server hooked up to our bismark mysql database.  It's basically a slick python wrapper for doing Web development with a database back-end.   The setup is ugly right now, but it's a proof of concept, and it works (django is talking to our back-end).  For example:
> http://networkdashboard.org:8000/summary/
> 
> Django has templates that will allow us to make this slick and pretty, but it's getting a little late for that tonight.
> 
> I think we can whip up some quick visualizations of what's in the DB with a nice Web page with some concerted python hacking.  For starters, it would be nice to have a version of the data whereby queries can actually complete in a reasonable time.  :-)  What's the best way to do this?  Split the table by months?
> 
> I will check what I have into the bismark source tree so that others can work on this.  (I'm looking at Abhishek :-)
> 
> -Nick
> _______________________________________________
> HNDR mailing list
> HNDR@lists.pixilab.org
> http://lists.pixilab.org/listinfo.cgi/hndr-pixilab.org

Re: [Bismark-devel] [Hndr] FCC app progress: django

[Dave Taht]

On 04/17/2011 11:57 PM, Nick Feamster wrote:
> (sorry for list cross-posting)
>
> Srikanth, Abhishek, Walter,
Taking walter and sri off the explicit cc list as both are already on 
bismark-devel.

> Small, slow progress on the FCC app---
>
> I have a written a very simple server with django.  I've got the django server hooked up to our bismark mysql database.  It's basically a slick python wrapper for doing Web development with a database back-end.   The setup is ugly right now, but it's a proof of concept, and it works (django is talking to our back-end).  For example:
> http://networkdashboard.org:8000/summary/
>
How we have configured the web servers here has had us survive several 
slashdottings.

http://www.bufferbloat.net/projects/bloat/wiki/Dogfood_Principle

Using fast cgi vs wsgi would probably lead to some security benefits and 
more predictable behavior, however it's a tossup.

http://docs.djangoproject.com/en/dev/howto/deployment/fastcgi/

> Django has templates that will allow us to make this slick and pretty, but it's getting a little late for that tonight.
>
> I think we can whip up some quick visualizations of what's in the DB with a nice Web page with some concerted python hacking.  For starters, it would be nice to have a version of the data whereby queries can actually complete in a reasonable time.  :-)  What's the best way to do this?  Split the table by months?
>

Your mysql configuration was an out of the box default one designed for 
very small databases. Yours is quite large. Increasing several buffer 
sizes by several orders of magnitude would help a lot.

Sri had made significant inroads into porting the database into postgres 
when I was there. Postgres is not only more highly performant and 
flexible than mysql, with a more capable parser, but has good analysis 
tools. It was my hope to benchmark some of your slowest existing queries 
using postgres's ANALYZE <query> tool to see how the design could be 
improved overall.

I did look over one of the slower (30+ seconds!) queries and suggested 
that a between statement be used instead of an and for the date range, 
but we never got around to testing that and mysql used to not be able to 
do anything sane with a between range (postgres can).

e.g:

mysql>  select dstport, sum(uppkts) as up_p, sum(dwpkts) as down_p, sum(upbytes) as up_bytes, sum(dwbytes) as down_bytes from FLOWS_newformat where tsstart>unix_timestamp('2011-2-6') and tsstart<unix_timestamp('2011-2-20') and deviceid='NB105' group by dstport order by down_bytes desc limit 20;

MIGHT do better with:

select dstport, sum(uppkts) as up_p, sum(dwpkts) as down_p, sum(upbytes) as up_bytes, sum(dwbytes) as down_bytes from FLOWS_newformat where tsstart between unix_timestamp('2011-2-6') and unix_timestamp('2011-2-20') and deviceid='NB105' group by dstport order by down_bytes desc limit 20;


I'd not be huge on divvying up tables by month, but creating summary 
tables by day and by hour would be a good idea. Usage patterns tend to 
be self-similar across day of week and by hour of day.

I note that it is important to be able to capture hour of day AT the 
location (EDT/MDT/PDT), as that is more self-similar that hour of day (UTC)

So the above becomes a nightly cron job in a specialized summary table, 
something like (untested)

drop table device_port_daily_summary;
create table device_port_daily_summary as

select deviceid, dstport, day(tsstart) as test_day, sum(uppkts) as up_p, sum(dwpkts) as down_p, sum(upbytes) as up_bytes, sum(dwbytes) as down_bytes from FLOWS_newformat group by deviceid, dstport, test_day


(although it would be mildly better to do this incrementally, creating a 
primary key on the first 3 fields, and perhaps reversing the order of 
primary fields above. Depends on the statistics)

> I will check what I have into the bismark source tree so that others can work on this.  (I'm looking at Abhishek :-)
>
While not exactly allergic to svn, I am a git fan-boy. Even when working 
with svn these days I use git-svn to cope with it (offline git logs 
rule). I'm not asking you to change your scm backend, just sayin...

[Bismark-devel] Dates are really tricky!!

[Dave Taht]

On 04/18/2011 06:18 AM, Dave Taht wrote:
> On 04/17/2011 11:57 PM, Nick Feamster wrote:
>
>> I think we can whip up some quick visualizations of what's in the DB 
>> with a nice Web page with some concerted python hacking.  For 
>> starters, it would be nice to have a version of the data whereby 
>> queries can actually complete in a reasonable time.  :-)  What's the 
>> best way to do this?  Split the table by months?
>>
> I did look over one of the slower (30+ seconds!) queries and suggested 
> that a between statement be used instead of an and for the date range, 
> but we never got around to testing that and mysql used to not be able 
> to do anything sane with a between range (postgres can).
>
> e.g:
>
> mysql>  select dstport, sum(uppkts) as up_p, sum(dwpkts) as down_p, 
> sum(upbytes) as up_bytes, sum(dwbytes) as down_bytes from 
> FLOWS_newformat where tsstart>unix_timestamp('2011-2-6') and 
> tsstart<unix_timestamp('2011-2-20') and deviceid='NB105' group by 
> dstport order by down_bytes desc limit 20;
>
> MIGHT do better with:
>
> select dstport, sum(uppkts) as up_p, sum(dwpkts) as down_p, 
> sum(upbytes) as up_bytes, sum(dwbytes) as down_bytes from 
> FLOWS_newformat where tsstart between unix_timestamp('2011-2-6') and 
> unix_timestamp('2011-2-20') and deviceid='NB105' group by dstport 
> order by down_bytes desc limit 20;
>
>
> I'd not be huge on divvying up tables by month, but creating summary 
> tables by day and by hour would be a good idea. Usage patterns tend to 
> be self-similar across day of week and by hour of day.
>
> I note that it is important to be able to capture hour of day AT the 
> location (EDT/MDT/PDT), as that is more self-similar that hour of day 
> (UTC)
>
To be clearer, what I suggest above is not solved by what I wrote below, 
and the below contained an error.

Coping with dates can be really tricky and should not be undertaken 
before my first cup of coffee.

http://www.postgresql.org/docs/8.2/static/datatype-datetime.html

> So the above becomes a nightly cron job in a specialized summary 
> table, something like (untested)
>
> drop table device_port_daily_summary;
> create table device_port_daily_summary as
>
select deviceid, dstport, day(tsstart) as test_day, EXTRACT(YEAR FROM 
TIMESTAMP tsstart) as test_year , sum(uppkts) as up_p, sum(dwpkts) as 
down_p, sum(upbytes) as up_bytes, sum(dwbytes) as down_bytes from 
FLOWS_newformat group by deviceid, dstport, test_day, test_year;

The way described below has a day-range of 0-365, which wasn't what you 
wanted. Days since the epoch or the start of database time would 
probably be better than explicitly storing the year... but I don't 
remember the good way of doing that.

Dates are tricky.

> select deviceid, dstport, day(tsstart) as test_day, sum(uppkts) as 
> up_p, sum(dwpkts) as down_p, sum(upbytes) as up_bytes, sum(dwbytes) as 
> down_bytes from FLOWS_newformat group by deviceid, dstport, test_day

would be wrong.

Re: [Bismark-devel] [Hndr] Dates are really tricky!!

[Marshini Chetty]

Hi all

This is awesome. At this rate, getting something together for the FCC competition seems very doable. 

M. 

Sent from my iPhone

On Apr 18, 2011, at 8:46 AM, Dave Taht <d@taht.net> wrote:

> On 04/18/2011 06:18 AM, Dave Taht wrote:
>> On 04/17/2011 11:57 PM, Nick Feamster wrote:
>> 
>>> I think we can whip up some quick visualizations of what's in the DB with a nice Web page with some concerted python hacking.  For starters, it would be nice to have a version of the data whereby queries can actually complete in a reasonable time.  :-)  What's the best way to do this?  Split the table by months?
>>> 
>> I did look over one of the slower (30+ seconds!) queries and suggested that a between statement be used instead of an and for the date range, but we never got around to testing that and mysql used to not be able to do anything sane with a between range (postgres can).
>> 
>> e.g:
>> 
>> mysql>  select dstport, sum(uppkts) as up_p, sum(dwpkts) as down_p, sum(upbytes) as up_bytes, sum(dwbytes) as down_bytes from FLOWS_newformat where tsstart>unix_timestamp('2011-2-6') and tsstart<unix_timestamp('2011-2-20') and deviceid='NB105' group by dstport order by down_bytes desc limit 20;
>> 
>> MIGHT do better with:
>> 
>> select dstport, sum(uppkts) as up_p, sum(dwpkts) as down_p, sum(upbytes) as up_bytes, sum(dwbytes) as down_bytes from FLOWS_newformat where tsstart between unix_timestamp('2011-2-6') and unix_timestamp('2011-2-20') and deviceid='NB105' group by dstport order by down_bytes desc limit 20;
>> 
>> 
>> I'd not be huge on divvying up tables by month, but creating summary tables by day and by hour would be a good idea. Usage patterns tend to be self-similar across day of week and by hour of day.
>> 
>> I note that it is important to be able to capture hour of day AT the location (EDT/MDT/PDT), as that is more self-similar that hour of day (UTC)
>> 
> To be clearer, what I suggest above is not solved by what I wrote below, and the below contained an error.
> 
> Coping with dates can be really tricky and should not be undertaken before my first cup of coffee.
> 
> http://www.postgresql.org/docs/8.2/static/datatype-datetime.html
> 
>> So the above becomes a nightly cron job in a specialized summary table, something like (untested)
>> 
>> drop table device_port_daily_summary;
>> create table device_port_daily_summary as
>> 
> select deviceid, dstport, day(tsstart) as test_day, EXTRACT(YEAR FROM TIMESTAMP tsstart) as test_year , sum(uppkts) as up_p, sum(dwpkts) as down_p, sum(upbytes) as up_bytes, sum(dwbytes) as down_bytes from FLOWS_newformat group by deviceid, dstport, test_day, test_year;
> 
> The way described below has a day-range of 0-365, which wasn't what you wanted. Days since the epoch or the start of database time would probably be better than explicitly storing the year... but I don't remember the good way of doing that.
> 
> Dates are tricky.
> 
>> select deviceid, dstport, day(tsstart) as test_day, sum(uppkts) as up_p, sum(dwpkts) as down_p, sum(upbytes) as up_bytes, sum(dwbytes) as down_bytes from FLOWS_newformat group by deviceid, dstport, test_day
> 
> would be wrong.
> 
> _______________________________________________
> HNDR mailing list
> HNDR@lists.pixilab.org
> http://lists.pixilab.org/listinfo.cgi/hndr-pixilab.org

Re: [Bismark-devel] [Hndr] Dates are really tricky!!

[Nick Feamster]

Dave,

Django does allow native SQL, but the cool thing about it is that most queries can be done with Python methods, that essentially do introspection on the database tables.  It's pretty slick.  Switching from mysql to postgres (when we are ready) is a one-line change.

I like the idea of generating summary tables per day.  That would _really_ speed things up, I think, and most people probably are just looking at the most recent queries by default.  Is this in the bug database yet?  I'll be happy to file it. :-)  Who is working on this part?

-Nick


On Apr 18, 2011, at 8:46 AM, Dave Taht wrote:

> On 04/18/2011 06:18 AM, Dave Taht wrote:
>> On 04/17/2011 11:57 PM, Nick Feamster wrote:
>> 
>>> I think we can whip up some quick visualizations of what's in the DB with a nice Web page with some concerted python hacking.  For starters, it would be nice to have a version of the data whereby queries can actually complete in a reasonable time.  :-)  What's the best way to do this?  Split the table by months?
>>> 
>> I did look over one of the slower (30+ seconds!) queries and suggested that a between statement be used instead of an and for the date range, but we never got around to testing that and mysql used to not be able to do anything sane with a between range (postgres can).
>> 
>> e.g:
>> 
>> mysql>  select dstport, sum(uppkts) as up_p, sum(dwpkts) as down_p, sum(upbytes) as up_bytes, sum(dwbytes) as down_bytes from FLOWS_newformat where tsstart>unix_timestamp('2011-2-6') and tsstart<unix_timestamp('2011-2-20') and deviceid='NB105' group by dstport order by down_bytes desc limit 20;
>> 
>> MIGHT do better with:
>> 
>> select dstport, sum(uppkts) as up_p, sum(dwpkts) as down_p, sum(upbytes) as up_bytes, sum(dwbytes) as down_bytes from FLOWS_newformat where tsstart between unix_timestamp('2011-2-6') and unix_timestamp('2011-2-20') and deviceid='NB105' group by dstport order by down_bytes desc limit 20;
>> 
>> 
>> I'd not be huge on divvying up tables by month, but creating summary tables by day and by hour would be a good idea. Usage patterns tend to be self-similar across day of week and by hour of day.
>> 
>> I note that it is important to be able to capture hour of day AT the location (EDT/MDT/PDT), as that is more self-similar that hour of day (UTC)
>> 
> To be clearer, what I suggest above is not solved by what I wrote below, and the below contained an error.
> 
> Coping with dates can be really tricky and should not be undertaken before my first cup of coffee.
> 
> http://www.postgresql.org/docs/8.2/static/datatype-datetime.html
> 
>> So the above becomes a nightly cron job in a specialized summary table, something like (untested)
>> 
>> drop table device_port_daily_summary;
>> create table device_port_daily_summary as
>> 
> select deviceid, dstport, day(tsstart) as test_day, EXTRACT(YEAR FROM TIMESTAMP tsstart) as test_year , sum(uppkts) as up_p, sum(dwpkts) as down_p, sum(upbytes) as up_bytes, sum(dwbytes) as down_bytes from FLOWS_newformat group by deviceid, dstport, test_day, test_year;
> 
> The way described below has a day-range of 0-365, which wasn't what you wanted. Days since the epoch or the start of database time would probably be better than explicitly storing the year... but I don't remember the good way of doing that.
> 
> Dates are tricky.
> 
>> select deviceid, dstport, day(tsstart) as test_day, sum(uppkts) as up_p, sum(dwpkts) as down_p, sum(upbytes) as up_bytes, sum(dwbytes) as down_bytes from FLOWS_newformat group by deviceid, dstport, test_day
> 
> would be wrong.
> 
> _______________________________________________
> HNDR mailing list
> HNDR@lists.pixilab.org
> http://lists.pixilab.org/listinfo.cgi/hndr-pixilab.org

Re: [Bismark-devel] [Hndr] Dates are really tricky!!

[Srikanth Sundaresan]

On Apr 18, 2011, at 10:11 AM, Nick Feamster wrote:

> I like the idea of generating summary tables per day.  That would _really_ speed things up, I think, and most people probably are just looking at the most recent queries by default. Is this in the bug database yet?  I'll be happy to file it. :-)  Who is working on this part?

Dave and I discussed this when he was visiting. I'm still not fully convinced that summary tables are the way to go unless we know exactly what we want.

- Srikanth

Re: [Bismark-devel] [Hndr] Dates are really tricky!!

[Nick Feamster]

On Apr 18, 2011, at 10:37 AM, Srikanth Sundaresan wrote:

> 
> On Apr 18, 2011, at 10:11 AM, Nick Feamster wrote:
> 
>> I like the idea of generating summary tables per day.  That would _really_ speed things up, I think, and most people probably are just looking at the most recent queries by default. Is this in the bug database yet?  I'll be happy to file it. :-)  Who is working on this part?
> 
> Dave and I discussed this when he was visiting. I'm still not fully convinced that summary tables are the way to go unless we know exactly what we want.

Cool.  Let's discuss at tomorrow's meeting?

It would be nice if we could do something that made the tables faster in one way or another (whether it means splitting by month, or by day).

-Nick

Re: [Bismark-devel] [Hndr] Dates are really tricky!!

[Dave Taht]

On 04/18/2011 08:39 AM, Nick Feamster wrote:
> On Apr 18, 2011, at 10:37 AM, Srikanth Sundaresan wrote:
>
>> On Apr 18, 2011, at 10:11 AM, Nick Feamster wrote:
>>
>>> I like the idea of generating summary tables per day.  That would _really_ speed things up, I think, and most people probably are just looking at the most recent queries by default. Is this in the bug database yet?  I'll be happy to file it. :-)  Who is working on this part?
>> Dave and I discussed this when he was visiting. I'm still not fully convinced that summary tables are the way to go unless we know exactly what we want.
Defining exactly what you want is a good idea. :)

I do note that the usage pattern by timezone thing is rather important, 
and very hard to do unless that data is captured about the device(s).

> Cool.  Let's discuss at tomorrow's meeting?
>
I can dial in if desired. 12?

> It would be nice if we could do something that made the tables faster in one way or another (whether it means splitting by month, or by day).
>
> -Nick

Re: [Bismark-devel] [Hndr] Dates are really tricky!!

[Beki Grinter]

[-- Attachment #1: Type: text/plain, Size: 1372 bytes --]

I think we cancelled tomorrow's meeting, I won't be there! But, I guess that does mean that others have the 12-1 slot back :)


beki

On Apr 18, 2011, at 10:39 AM, Nick Feamster wrote:

> 
> On Apr 18, 2011, at 10:37 AM, Srikanth Sundaresan wrote:
> 
>> 
>> On Apr 18, 2011, at 10:11 AM, Nick Feamster wrote:
>> 
>>> I like the idea of generating summary tables per day.  That would _really_ speed things up, I think, and most people probably are just looking at the most recent queries by default. Is this in the bug database yet?  I'll be happy to file it. :-)  Who is working on this part?
>> 
>> Dave and I discussed this when he was visiting. I'm still not fully convinced that summary tables are the way to go unless we know exactly what we want.
> 
> Cool.  Let's discuss at tomorrow's meeting?
> 
> It would be nice if we could do something that made the tables faster in one way or another (whether it means splitting by month, or by day).
> 
> -Nick
> _______________________________________________
> HNDR mailing list
> HNDR@lists.pixilab.org
> http://lists.pixilab.org/listinfo.cgi/hndr-pixilab.org

---
Beki Grinter
Associate Professor, School of Interactive Computing
Georgia Institute of Technology

http://www.cc.gatech.edu/~beki
beki70.wordpress.com
AIM, Skype, Twitter, FourSquare, Flickr, etc..: beki70








[-- Attachment #2: Type: text/html, Size: 20339 bytes --]

Re: [Bismark-devel] [Hndr] Dates are really tricky!!

[Nick Feamster]

Oh yes... I would like to go to Marshini's defense lunch.  Perhaps we should all go to that.  Is it a conflict of interest for me to suggest that? :-)

Maybe we can push the meeting into the afternoon?

-Nick

On Apr 18, 2011, at 10:58 AM, Beki Grinter wrote:

> I think we cancelled tomorrow's meeting, I won't be there! But, I guess that does mean that others have the 12-1 slot back :)
> 
> 
> beki
> 
> On Apr 18, 2011, at 10:39 AM, Nick Feamster wrote:
> 
>> 
>> On Apr 18, 2011, at 10:37 AM, Srikanth Sundaresan wrote:
>> 
>>> 
>>> On Apr 18, 2011, at 10:11 AM, Nick Feamster wrote:
>>> 
>>>> I like the idea of generating summary tables per day.  That would _really_ speed things up, I think, and most people probably are just looking at the most recent queries by default. Is this in the bug database yet?  I'll be happy to file it. :-)  Who is working on this part?
>>> 
>>> Dave and I discussed this when he was visiting. I'm still not fully convinced that summary tables are the way to go unless we know exactly what we want.
>> 
>> Cool.  Let's discuss at tomorrow's meeting?
>> 
>> It would be nice if we could do something that made the tables faster in one way or another (whether it means splitting by month, or by day).
>> 
>> -Nick
>> _______________________________________________
>> HNDR mailing list
>> HNDR@lists.pixilab.org
>> http://lists.pixilab.org/listinfo.cgi/hndr-pixilab.org
> 
> ---
> Beki Grinter
> Associate Professor, School of Interactive Computing
> Georgia Institute of Technology
> 
> http://www.cc.gatech.edu/~beki
> beki70.wordpress.com
> AIM, Skype, Twitter, FourSquare, Flickr, etc..: beki70
> 
> 
> 
> 
> 
> 
> 

Re: [Bismark-devel] [Hndr] Dates are really tricky!!

[Marshini Chetty]

[-- Attachment #1: Type: text/plain, Size: 2270 bytes --]

Hi all

The lunch will be at Mid-city cafe at noon if anyone is interested in
joining. I won't be able to make the afternoon meeting.

M.

On Mon, Apr 18, 2011 at 11:03 AM, Nick Feamster <feamster@cc.gatech.edu>wrote:

> Oh yes... I would like to go to Marshini's defense lunch.  Perhaps we
> should all go to that.  Is it a conflict of interest for me to suggest that?
> :-)
>
> Maybe we can push the meeting into the afternoon?
>
> -Nick
>
> On Apr 18, 2011, at 10:58 AM, Beki Grinter wrote:
>
> > I think we cancelled tomorrow's meeting, I won't be there! But, I guess
> that does mean that others have the 12-1 slot back :)
> >
> >
> > beki
> >
> > On Apr 18, 2011, at 10:39 AM, Nick Feamster wrote:
> >
> >>
> >> On Apr 18, 2011, at 10:37 AM, Srikanth Sundaresan wrote:
> >>
> >>>
> >>> On Apr 18, 2011, at 10:11 AM, Nick Feamster wrote:
> >>>
> >>>> I like the idea of generating summary tables per day.  That would
> _really_ speed things up, I think, and most people probably are just looking
> at the most recent queries by default. Is this in the bug database yet?
>  I'll be happy to file it. :-)  Who is working on this part?
> >>>
> >>> Dave and I discussed this when he was visiting. I'm still not fully
> convinced that summary tables are the way to go unless we know exactly what
> we want.
> >>
> >> Cool.  Let's discuss at tomorrow's meeting?
> >>
> >> It would be nice if we could do something that made the tables faster in
> one way or another (whether it means splitting by month, or by day).
> >>
> >> -Nick
> >> _______________________________________________
> >> HNDR mailing list
> >> HNDR@lists.pixilab.org
> >> http://lists.pixilab.org/listinfo.cgi/hndr-pixilab.org
> >
> > ---
> > Beki Grinter
> > Associate Professor, School of Interactive Computing
> > Georgia Institute of Technology
> >
> > http://www.cc.gatech.edu/~beki
> > beki70.wordpress.com
> > AIM, Skype, Twitter, FourSquare, Flickr, etc..: beki70
> >
> >
> >
> >
> >
> >
> >
>
> _______________________________________________
> HNDR mailing list
> HNDR@lists.pixilab.org
> http://lists.pixilab.org/listinfo.cgi/hndr-pixilab.org
>



-- 
-----------------------
Marshini Chetty
HCC PhD Candidate
College of Computing
Georgia Institute of Technology
www.cc.gatech.edu/~marshini

[-- Attachment #2: Type: text/html, Size: 3486 bytes --]

Re: [Bismark-devel] [Hndr] Dates are really tricky!!

[Keith Edwards]

[-- Attachment #1: Type: text/plain, Size: 2704 bytes --]

I'm booked all afternoon (including lunch), so won't be able to make the social outing or an afternoon unfortunately...

-k

On Apr 18, 2011, at 11:35 AM, Marshini Chetty wrote:

> Hi all
> 
> The lunch will be at Mid-city cafe at noon if anyone is interested in joining. I won't be able to make the afternoon meeting.
> 
> M.
> 
> On Mon, Apr 18, 2011 at 11:03 AM, Nick Feamster <feamster@cc.gatech.edu> wrote:
> Oh yes... I would like to go to Marshini's defense lunch.  Perhaps we should all go to that.  Is it a conflict of interest for me to suggest that? :-)
> 
> Maybe we can push the meeting into the afternoon?
> 
> -Nick
> 
> On Apr 18, 2011, at 10:58 AM, Beki Grinter wrote:
> 
> > I think we cancelled tomorrow's meeting, I won't be there! But, I guess that does mean that others have the 12-1 slot back :)
> >
> >
> > beki
> >
> > On Apr 18, 2011, at 10:39 AM, Nick Feamster wrote:
> >
> >>
> >> On Apr 18, 2011, at 10:37 AM, Srikanth Sundaresan wrote:
> >>
> >>>
> >>> On Apr 18, 2011, at 10:11 AM, Nick Feamster wrote:
> >>>
> >>>> I like the idea of generating summary tables per day.  That would _really_ speed things up, I think, and most people probably are just looking at the most recent queries by default. Is this in the bug database yet?  I'll be happy to file it. :-)  Who is working on this part?
> >>>
> >>> Dave and I discussed this when he was visiting. I'm still not fully convinced that summary tables are the way to go unless we know exactly what we want.
> >>
> >> Cool.  Let's discuss at tomorrow's meeting?
> >>
> >> It would be nice if we could do something that made the tables faster in one way or another (whether it means splitting by month, or by day).
> >>
> >> -Nick
> >> _______________________________________________
> >> HNDR mailing list
> >> HNDR@lists.pixilab.org
> >> http://lists.pixilab.org/listinfo.cgi/hndr-pixilab.org
> >
> > ---
> > Beki Grinter
> > Associate Professor, School of Interactive Computing
> > Georgia Institute of Technology
> >
> > http://www.cc.gatech.edu/~beki
> > beki70.wordpress.com
> > AIM, Skype, Twitter, FourSquare, Flickr, etc..: beki70
> >
> >
> >
> >
> >
> >
> >
> 
> _______________________________________________
> HNDR mailing list
> HNDR@lists.pixilab.org
> http://lists.pixilab.org/listinfo.cgi/hndr-pixilab.org
> 
> 
> 
> -- 
> -----------------------
> Marshini Chetty
> HCC PhD Candidate
> College of Computing
> Georgia Institute of Technology
> www.cc.gatech.edu/~marshini
> _______________________________________________
> HNDR mailing list
> HNDR@lists.pixilab.org
> http://lists.pixilab.org/listinfo.cgi/hndr-pixilab.org


[-- Attachment #2: Type: text/html, Size: 4075 bytes --]